Interesting, so you are suggesting that we drop Kafka's current versioning scheme (0.major.minor.patch)? I can see the reasoning for doing so now.
However, I think I'd prefer to do that when we do the 1.x bump, which I think we should do once exactly-once lands. That way people only have to re-learn what Kafka version numbers mean exactly once (and the 1.x bump is a good signal that something has changed with regards to that). I don't feel too strongly though, so I would be OK with the other way if others feel that it's better. If we were to keep the existing versioning, it would look like: Feature releases will be a minor release by default 0.10.1, 0.10.2 - unless: 1. We break compatibility (i.e. remove deprecated public methods after a reasonable period), in which case we bump to 0.11.x 2. We change the message format, in which case we bump to 0.11.x 3. We do something totally amazing (exactly once?) and decide to bump to 1.X to celebrate It's worth noting that 0.9.0.0 was an exception in that we bumped to the next version because it had lots of new features even though it was not incompatible. Also, we consider new protocol versions as compatible in minor releases even though it's not entirely true (the Java clients cannot talk to older brokers if there are new protocol versions that they use). We don't introduce new protocol versions in patch releases. Ismael P.S. I wrote this in parallel to Jun's message On Fri, Aug 12, 2016 at 9:17 PM, Gwen Shapira <g...@confluent.io> wrote: > Good question! > > My thoughts are... bugfix releases will be done "as needed" based on > community feedback > > Feature releases will be a minor release by default 0.11, 0.12 - unless: > 1. We manage to break compatibility completely (we shouldn't) in which > case we need to bump to 1.X > 2. We do something totally amazing (exactly once?) and decide to bump > to 1.X to celebrate > 3. The release manager decides that the features in the release are > not very exciting and we can go with 0.10.1 (i.e very minor release) > > Does that make sense? > > On Fri, Aug 12, 2016 at 10:25 AM, Nacho Solis > <nso...@linkedin.com.invalid> wrote: > > How would time releases relate to versions? (Major, minor, API > > compatibility, etc). > > > > On Thu, Aug 11, 2016 at 9:37 AM, Guozhang Wang <wangg...@gmail.com> > wrote: > > > >> I think we do not need to make the same guarantee as for "how old of > your > >> Kafka version that you can upgrade to the latest in one shot" (just > call it > >> "upgrade maintenance" for short) and "how old of your Kafka version that > >> you can enjoy backport critical bug fixes from the latest version" > (call it > >> "bugfix backport maintenance" for short). > >> > >> Upgrade maintenance: I think 2 years is a good cadence, and we can use > the > >> same policy for getting rid of obsolete APIs / protocols as well. I.e. > say > >> we release 0.10.1.0 in 2017FEB then we can in that release drop > obsoleted > >> code in 0.8.2 (released in 2015FEB), such that users cannot directly > >> upgrade from 0.8.2.x to 0.10.1.x, but needs to have another hop. > >> > >> Bugfix backports maintenance: if we release every 4 months, then > current + > >> 2 older means we have one year period for back-port critical bug fixes, > >> which sounds good to me; if we release every 3 months, then probably we > >> should have current + 3 older. > >> > >> > >> Guozhang > >> > >> > >> On Thu, Aug 11, 2016 at 12:14 AM, Ismael Juma <ism...@juma.me.uk> > wrote: > >> > >> > Do we need to make a decision on this particular point? Could we gauge > >> > community demand (people tend to ask for fixes to be backported in > JIRA) > >> > and decide then? > >> > > >> > If we make a good job of avoiding regressions, then it seems that each > >> > branch should really only need one or or a maximum of two bug fix > >> releases. > >> > After that, users are welcome to upgrade to a new feature release (and > >> > hopefully to the most current) to get non-critical fixes and > features. An > >> > exception is if we get security fixes. We probably do need a policy > for > >> how > >> > far we backport those. > >> > > >> > Ismael > >> > > >> > On Thu, Aug 11, 2016 at 4:35 AM, Gwen Shapira <g...@confluent.io> > wrote: > >> > > >> > > Yeah, I agree that maintaining 6 release branches is not really > >> > > sustainable... > >> > > > >> > > Maybe 3 (current and 2 older) makes sense? > >> > > > >> > > On Wed, Aug 10, 2016 at 7:35 PM, Joel Koshy <jjkosh...@gmail.com> > >> wrote: > >> > > > On Wed, Aug 10, 2016 at 5:44 PM, Joel Koshy <jjkosh...@gmail.com> > >> > wrote: > >> > > > > >> > > >> > >> > > >> > >> > > >> On Tue, Aug 9, 2016 at 4:49 PM, Gwen Shapira <g...@confluent.io> > >> > wrote: > >> > > >> > >> > > >>> > >> > > >>> 4. Frequent releases mean we need to do bugfix releases for > older > >> > > >>> branches. Right now we only do bugfix releases to latest > release. > >> > > >>> > >> > > >> > >> > > >> I'm a bit unclear on how the above is a side-effect of time-based > >> > > >> releases. IIUC this just changes how frequently we release off > the > >> > > current > >> > > >> release branch right? Or put another way, are you also proposing > any > >> > > >> fundamental change to our versioning/branching scheme? > >> > > >> > >> > > > > >> > > > Actually nm - so what you're saying is we cut more frequently off > >> trunk > >> > > > which means having to maintaining multiple release branches. > However, > >> > the > >> > > > more frequently we release then it should be less difficult to > >> upgrade > >> > > from > >> > > > one release to another which means it should be reasonable to > expect > >> > that > >> > > > we EOL release branches sooner than later. > >> > > > > >> > > > However, if we are expected to maintain release branches for up to > >> two > >> > > > years then that means potential bugfix releases for up to eight > >> release > >> > > > branches at any given time? i.e., it seems that a short > inter-release > >> > > > interval would require us to EOL release branches sooner than > that to > >> > > make > >> > > > things manageable. > >> > > > >> > > > >> > > > >> > > -- > >> > > Gwen Shapira > >> > > Product Manager | Confluent > >> > > 650.450.2760 | @gwenshap > >> > > Follow us: Twitter | blog > >> > > > >> > > >> > >> > >> > >> -- > >> -- Guozhang > >> > > > > > > > > -- > > Nacho (Ignacio) Solis > > nso...@linkedin.com > > > > -- > Gwen Shapira > Product Manager | Confluent > 650.450.2760 | @gwenshap > Follow us: Twitter | blog >
