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
