Re: [DISCUSS] 2017 October release planning and release version

2017-07-25 Thread Ismael Juma
Thanks Sonke, that's great. I filed an initial JIRA: https://issues.apache.org/jira/browse/KAFKA-5637 As per our offline conversation, you captured the thread discussion already, so feel free to flesh out the JIRA. Ismael On Mon, Jul 24, 2017 at 8:45 PM, Sönke Liebau <

Re: [DISCUSS] 2017 October release planning and release version

2017-07-25 Thread Guozhang Wang
Makes sense, have updated the wiki page to use dashes for rc numbers. Guozhang On Tue, Jul 25, 2017 at 3:40 AM, Ismael Juma wrote: > On Tue, Jul 18, 2017 at 4:04 PM, Guozhang Wang wrote: > > > I was actually thinking about using dot as well for the rc as

Re: [DISCUSS] 2017 October release planning and release version

2017-07-25 Thread Ismael Juma
On Tue, Jul 18, 2017 at 4:04 PM, Guozhang Wang wrote: > I was actually thinking about using dot as well for the rc as well moving > forward, but I can be convinced if we have some reason to keep it as dash > as well. It seems reasonable to use a dash for the RC part as it's

Re: [DISCUSS] 2017 October release planning and release version

2017-07-24 Thread Guozhang Wang
Hello, Since I have not heard any further comments till now. I will close this discussion and formally name our next major release (this coming Oct.) 1.0.0; will update the wiki pages accordingly. Sönke, Thanks for volunteering in documenting the release logistics. I'll leave it to Ismael to

Re: [DISCUSS] 2017 October release planning and release version

2017-07-24 Thread Sönke Liebau
I am happy to volunteer for working on documenting the release logistics and related topics if someone is needed for that part. Best regards, Sönke Am 24.07.2017 9:28 nachm. schrieb "Guozhang Wang" : > Thanks for everyone who has shared their thoughts and feedbacks to this >

Re: [DISCUSS] 2017 October release planning and release version

2017-07-24 Thread Guozhang Wang
Thanks for everyone who has shared their thoughts and feedbacks to this discussion. Here is my conclusion: 1. So far everyone has agreed on naming the next major release version to 1.0; if I did not hear any other opinions by the end of today PDT time I will name the next release as 1.0.0 and

Re: [DISCUSS] 2017 October release planning and release version

2017-07-24 Thread Becket Qin
+1 on 1.0. I think it makes a lot of sense given the point Kafka is now. To me Kafka has absolutely reached 1.0 in terms of features/functions. That said, I do share the same opinion with others that the usablity and policies might still need some improvement to meet the 1.0 standard. On Sat, Jul

Re: [DISCUSS] 2017 October release planning and release version

2017-07-22 Thread Matthias J. Sax
I agree with Ismael. If we go for 1.0 (what I do support), we need to meet people's expectations and should document all policies and guarantees explicitly. We might also consider to support older releases longer and do bug fix release for older releases, too. Other projects (like Flink) do a

Re: [DISCUSS] 2017 October release planning and release version

2017-07-21 Thread Sriram Subramanian
+1! On Fri, Jul 21, 2017 at 12:35 PM, Jay Kreps wrote: > 1.0! Let's do it! > > -Jay > > On Tue, Jul 18, 2017 at 3:36 PM, Guozhang Wang wrote: > > > Hi all, > > > > With 0.11.0.0 out of the way, I would like to volunteer to be the > > release manager > >

Re: [DISCUSS] 2017 October release planning and release version

2017-07-21 Thread Guozhang Wang
That's fair enough too. Guozhang On Fri, Jul 21, 2017 at 12:13 PM, Ismael Juma wrote: > Yes, I agree that the choice of version number can be done separately. > That's why I said I'd file a separate JIRA for the documentation > improvements. Having said that, there are some

Re: [DISCUSS] 2017 October release planning and release version

2017-07-21 Thread Jay Kreps
1.0! Let's do it! -Jay On Tue, Jul 18, 2017 at 3:36 PM, Guozhang Wang wrote: > Hi all, > > With 0.11.0.0 out of the way, I would like to volunteer to be the > release manager > for our next time-based feature release. See https://cwiki.apache.org/ >

Re: [DISCUSS] 2017 October release planning and release version

2017-07-21 Thread Ismael Juma
Yes, I agree that the choice of version number can be done separately. That's why I said I'd file a separate JIRA for the documentation improvements. Having said that, there are some expectations that people have for projects that have reached 1.0.0 and we should try to allocate time for the

Re: [DISCUSS] 2017 October release planning and release version

2017-07-21 Thread Guozhang Wang
Thanks Ismael. I agree with you on all these points, and for some of these points like 3) we never have a written-down policy though in practice we tend to follow some patterns. To me deciding what's the version number of the next major release does not necessarily mean we need now to change any

Re: [DISCUSS] 2017 October release planning and release version

2017-07-21 Thread Ismael Juma
On the topic of documentation, we should also document which releases are still supported and which are not. There a few factors to consider: 1. Which branches receive bug fixes. We typically backport fixes to the two most recent stable branches (the most recent stable branch typically gets more

Re: [DISCUSS] 2017 October release planning and release version

2017-07-21 Thread Michal Borowiecki
+1 for 1.0 (not for 12.0) On 21/07/17 15:59, Michael Pearce wrote: +1 Why not just drop the leading 0, and call next version 12.0.0 instead of 1.0.0, I think in my head I’ve always just dropped the leading 0 anyhow. On 21/07/2017, 04:15, "Neha Narkhede" wrote: +1

Re: [DISCUSS] 2017 October release planning and release version

2017-07-21 Thread Michael Pearce
+1 Why not just drop the leading 0, and call next version 12.0.0 instead of 1.0.0, I think in my head I’ve always just dropped the leading 0 anyhow. On 21/07/2017, 04:15, "Neha Narkhede" wrote: +1 on 1.0. It's about time :) On Thu, Jul 20, 2017 at 5:11 PM Ewen

Re: [DISCUSS] 2017 October release planning and release version

2017-07-20 Thread Neha Narkhede
+1 on 1.0. It's about time :) On Thu, Jul 20, 2017 at 5:11 PM Ewen Cheslack-Postava wrote: > Ack on the deprecation, as long as we actually give people the window. I > guess we're not doing a good job of communicating what that period is > anyway, so we can play a bit fast and

Re: [DISCUSS] 2017 October release planning and release version

2017-07-20 Thread Ewen Cheslack-Postava
Ack on the deprecation, as long as we actually give people the window. I guess we're not doing a good job of communicating what that period is anyway, so we can play a bit fast and loose. -Ewen On Thu, Jul 20, 2017 at 4:59 PM, Guozhang Wang wrote: > We do have the KIP in

Re: [DISCUSS] 2017 October release planning and release version

2017-07-20 Thread Guozhang Wang
We do have the KIP in the candidate list of the next release (see wiki https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+2017.Oct) as KIP-118: Drop Support for Java 7 in Kafka 0.11 .

Re: [DISCUSS] 2017 October release planning and release version

2017-07-20 Thread Guozhang Wang
That's a good question, from https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+0.11.0.0 it seems we do have one deprecation (KIP-109: Old Consumer Deprecation ). I'm fine with not removing the

Re: [DISCUSS] 2017 October release planning and release version

2017-07-20 Thread Ismael Juma
We deprecated the old Scala consumers and some Stream APIs that I can remember. I can't comment on the Streams APIs, but we don't intend to remove the old Scala consumers before the June 2018 release (we said we'd keep it for at least one year after deprecation). Ismael Ismael On 21 Jul 2017

Re: [DISCUSS] 2017 October release planning and release version

2017-07-20 Thread Ewen Cheslack-Postava
Did we deprecate anything in 0.11.0? The one concern with bumping major versions in consecutive releases is that you may not give people the room for transition if you deprecate and then immediately remove in the next release. -Ewen On Thu, Jul 20, 2017 at 4:51 AM, Damian Guy

Re: [DISCUSS] 2017 October release planning and release version

2017-07-20 Thread Damian Guy
+1 on 1.0! Are we also going to move to java 8? I also think we should drop the Unstable annotations completely. Cheers, Damian On Wed, 19 Jul 2017 at 21:36 Guozhang Wang wrote: > Hi Stevo, > > Just trying to add to what Ismael has already replied you: > > > >

Re: [DISCUSS] 2017 October release planning and release version

2017-07-19 Thread Guozhang Wang
Hi Stevo, Just trying to add to what Ismael has already replied you: > Practice/"features" like protocol version being a parameter, and defaulting > to latest so auto updated with dependency update which introduces new > protocol/behavior should not be used in public client APIs. To switch >

Re: [DISCUSS] 2017 October release planning and release version

2017-07-19 Thread Ismael Juma
Hi Stevo, Thanks for your feedback. We should definitely do a better job of documenting things. We basically follow semantic versioning, but it's currently a bit confusing because: 1. There are 4 segments in the version. The "0." part should be ignored when deciding what is major, minor and

Re: [DISCUSS] 2017 October release planning and release version

2017-07-19 Thread Stevo Slavić
With 0.x version of project at least I found lots of unexpected painful things acceptable. Graduating from 0.*, with x.y.z semantic versioning IMO it should be clearly communicated to community is there change in meaning, what's the "SLO", what are the commitments, what change in every segment

Re: [DISCUSS] 2017 October release planning and release version

2017-07-18 Thread Ismael Juma
With regards to the annotations, I think we should expect that we'll always have some @Evolving APIs. Even though much of the platform is mature, we'll continue to improve and extend it. I'm generally not a fan of @Unstable (since there's rarely a reason to make breaking changes in bug fix

Re: [DISCUSS] 2017 October release planning and release version

2017-07-18 Thread Guozhang Wang
Currently the only @unstable annotations left are on Streams and one class of Security modules, and I think we have a good chance of removing them all in the next release. We also have a few @evolving annotations on the Admin, Streams, Security modules etc. And I think we can try to also

Re: [DISCUSS] 2017 October release planning and release version

2017-07-18 Thread Guozhang Wang
On Tue, Jul 18, 2017 at 3:42 PM, Ismael Juma wrote: > Hi Guozhang, > > Thanks for volunteering to be the release manager for the next release! > > I am +1 on naming the next release 1.0.0. As you said, Kafka is mature > enough and this will make it easier for others to

Re: [DISCUSS] 2017 October release planning and release version

2017-07-18 Thread Gwen Shapira
Also fine with the change in general. As you mentioned, 1.x indicates mature APIs, compatibility and stability. Are we going to remove the @unstable annotations in this release? Gwen On Tue, Jul 18, 2017 at 3:43 PM Ismael Juma wrote: > Hi Guozhang, > > Thanks for

Re: [DISCUSS] 2017 October release planning and release version

2017-07-18 Thread Ismael Juma
Hi Guozhang, Thanks for volunteering to be the release manager for the next release! I am +1 on naming the next release 1.0.0. As you said, Kafka is mature enough and this will make it easier for others to understand our versioning policy. A couple of minor questions inline. On Tue, Jul 18,

[DISCUSS] 2017 October release planning and release version

2017-07-18 Thread Guozhang Wang
Hi all, With 0.11.0.0 out of the way, I would like to volunteer to be the release manager for our next time-based feature release. See https://cwiki.apache.org/ confluence/display/KAFKA/Time+Based+Release+Plan if you missed previous communication on time-based releases or need a reminder. I put