Right now, our major releases are really indicated in the second digit, not in the leading 0. So 0.10 is a major, 0.10.1 is a minor and 0.10.0.1 is a bug fix.
Thanks, Jun On Fri, Aug 12, 2016 at 1: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 >
