kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Pearce <Michael.Pea...@ig.com>
Subject Re: [DISCUSS] 0.10.1.1 Plan
Date Sat, 26 Nov 2016 07:13:31 GMT
As agreed that this should be purely a bug fix release for stability.


I'd like to flag then we shouldn't be adding / merging in any Jira's that are not bugs.

e.g. KAFKA-4438


________________________________________
From: ismaelj@gmail.com <ismaelj@gmail.com> on behalf of Ismael Juma <ismael@juma.me.uk>
Sent: Friday, November 25, 2016 11:43 AM
To: dev@kafka.apache.org
Subject: Re: [DISCUSS] 0.10.1.1 Plan

Good, seems like we are in agreement about sticking to bug fixes for
0.10.1.1.

Regarding the removal of final, I understand that it doesn't break
backwards binary compatibility (it does break forwards compatibility and
hence why it's more suited for feature releases; these are the same rules
followed by the JDK and Scala).

It's probably best to discuss this in another thread, but to clarify: the
point I was making is that once you make a class non final, maintaining
compatibility becomes more complex. You have to take into account that
methods could have been overridden, for example. As such, some thought
should be given to the scenarios under which classes can be extended, how
we will ensure that we can evolve the class without breaking users, whether
we want to make some methods final, whether we should add some
documentation guiding users regarding good/bad examples of inheritance
versus composition for these classes and so on. This is particularly
important for core client classes exposed by the consumer and producer and
it is the approach taken by projects that have a good track record with
regards to maintaining compatibility for long periods of time. I didn't see
much discussion or reasoning along the lines above for the
ProducerRecord/ConsumerRecord change and hence my comment (even if it may
actually me a good change once all is considered).

Ismael

On Thu, Nov 24, 2016 at 7:56 PM, Michael Pearce <Michael.Pearce@ig.com>
wrote:

> +1 it would be nice, and as is less restrive would not cause any issue.
>
> Saying that agree this is a fix build not a feature build.
>
> Sent using OWA for iPhone
> ________________________________________
> From: Rajini Sivaram <rajinisivaram@googlemail.com>
> Sent: Thursday, November 24, 2016 12:17:13 PM
> To: dev@kafka.apache.org
> Subject: Re: [DISCUSS] 0.10.1.1 Plan
>
> Hi Ismael,
>
> OK, I do agree with you. At the moment, our code wraps these three classes
> since they can't be extended. I recently noticed that two of the three are
> now non-final in trunk. If all three were made non-final, we would like to
> extend them,
>
> According to the Java specification:
>
> *Changing a class that is declared final to no longer be
> declared final does not break compatibility with pre-existing binaries.*
>
>
> So it shouldn't break anything. Perhaps that is the reason why KAFKA-4250
> was merged (I hadn't even noticed it). It is not critical, so I am ok with
> it not being in the patch release.
>
>
> On Thu, Nov 24, 2016 at 11:43 AM, Ismael Juma <ismaelj@gmail.com> wrote:
>
> > Hi Rajini,
> >
> > I think we should avoid making changes like that in patch releases as it
> > means that code that compiles with 0.10.1.1 may not compile with
> 0.10.1.0.
> > Since we now have frequent time based releases, I think it makes sense
> for
> > patch releases to only include bug fixes and test stability fixes.
> >
> > About the specific changes that you mention, I didn't see a discussion
> > about compatibility guarantees that are expected by people who subclass
> > these classes so I think it was a bit premature to merge the
> ProducerRecord
> > and ConsumerRecord final removal change.
> >
> > Ismael
> >
> > On 24 Nov 2016 10:26 am, "Rajini Sivaram" <rajinisivaram@googlemail.com>
> > wrote:
> >
> > > Can we add KAFKA-4440 and KAFKA-4250 to the the list? They make
> > > ProducerRecord/ConsumerRecord/RecordMetadata non-final so that they
> can
> > be
> > > extended. The changes have minimal impact on the codebase, but will
> > really
> > > help when implementing other producers/consumers. It is not a bug-fix,
> > but
> > > if we are going to make the change, it will be good to have it in a
> > release
> > > soon.
> > >
> > > Thank you,
> > >
> > > Rajini
> > >
> > >
> > > On Thu, Nov 24, 2016 at 4:36 AM, Bernard Leach <
> leachbj@bouncycastle.org
> > >
> > > wrote:
> > >
> > > > Hi Guozhang,
> > > >
> > > > I have added KAFKA-4438 to that list as that would enable publishing
> > the
> > > > scala 2.12 builds of 0.10.1.1.  There are other tasks in order to
> > > actually
> > > > publish a 2.12 but merging that change would enable that process.
> > > There’s
> > > > a corresponding PR on github that consists of a cherry-pick of the
> > > > corresponding change from trunk.
> > > >
> > > > cheers,
> > > > bern
> > > >
> > > > > On 24 Nov 2016, at 06:58, Guozhang Wang <wangguoz@gmail.com>
> wrote:
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > We have resolved 15 JIRAs including a few critical bugs in the
> 0.10.1
> > > > > branch since 0.10.1.0 was released so I'd like to propose to
> release
> > > > > 0.10.1.1 soon:
> > > > >
> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Fixed%20AND%
> > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > > 20DESC%2C%20key%20DESC
> > > > >
> > > > > There are still a few outstanding issues that are not unresolved
> and
> > > have
> > > > > 0.10.1.1 as the target version:
> > > > >
> > > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20KAFKA%20AND%20resolution%20%3D%20Unresolved%20AND%
> > > > 20fixVersion%20%3D%200.10.1.1%20ORDER%20BY%20priority%
> > > > 20DESC%2C%20key%20DESC
> > > > >
> > > > > Once we have resolved these issues I will start the release
> process.
> > > > >
> > > > > --
> > > > > -- Guozhang
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > >
> > > Rajini
> > >
> >
>
>
>
> --
> Regards,
>
> Rajini
> The information contained in this email is strictly confidential and for
> the use of the addressee only, unless otherwise indicated. If you are not
> the intended recipient, please do not read, copy, use or disclose to others
> this message or any attachment. Please also notify the sender by replying
> to this email or by telephone (+44(020 7896 0011) and then delete the
> email and any copies of it. Opinions, conclusion (etc) that do not relate
> to the official business of this company shall be understood as neither
> given nor endorsed by it. IG is a trading name of IG Markets Limited (a
> company registered in England and Wales, company number 04008957) and IG
> Index Limited (a company registered in England and Wales, company number
> 01190902). Registered address at Cannon Bridge House, 25 Dowgate Hill,
> London EC4R 2YA. Both IG Markets Limited (register number 195355) and IG
> Index Limited (register number 114059) are authorised and regulated by the
> Financial Conduct Authority.
>
The information contained in this email is strictly confidential and for the use of the addressee
only, unless otherwise indicated. If you are not the intended recipient, please do not read,
copy, use or disclose to others this message or any attachment. Please also notify the sender
by replying to this email or by telephone (+44(020 7896 0011) and then delete the email and
any copies of it. Opinions, conclusion (etc) that do not relate to the official business of
this company shall be understood as neither given nor endorsed by it. IG is a trading name
of IG Markets Limited (a company registered in England and Wales, company number 04008957)
and IG Index Limited (a company registered in England and Wales, company number 01190902).
Registered address at Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Both IG Markets
Limited (register number 195355) and IG Index Limited (register number 114059) are authorised
and regulated by the Financial Conduct Authority.

Mime
View raw message