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
