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
