Thats good feedback, thanks. I don't think you were involved in the previous release, but we did try to follow the model you suggest. We announced few weeks before cutting branches and gave time for features and stabilization. This started a mad last-minute rush of semi-baked features that forced 6 (or 7) release candidates and significant delays.
I think (but can't know) that part of the reason is that people felt compelled to get features in to the nearest release, because who knows when the next one will happen. Scheduled releases can take some of the stress and pressure off the process (we hope) - you miss this train and the next will show up. This is obviously just a reasoned guess, we won't know without trying. But since we did try feature releases and ran into difficulties, I thought we can experiment with something different. After 3 releases (i.e. this time next year), we can circle back and see how everyone feels and whether we need to adjust course. I am fairly confident that with 4 month per release and one month for stability we'll have both features and sufficient testing (already the next release will have the admin protocols, which is huge, time-based indexes, connector improvements, throttling... it will be a good one!). But we won't know for sure until we try I do agree with you that Ubuntu is not the right model for us. I am more inspired by Cassandra that has similar product with a rather similar community, and are doing time-based releases successfully. Gwen On Fri, Aug 12, 2016 at 2:35 PM, Nacho Solis <nso...@linkedin.com.invalid> wrote: > I'm not convinced that time-based releases for this type of development are > the right thing. > > Something like Ubuntu, where all components are moving targets needs to > decide to freeze and release without having full coordination from the > participants. There is no guarantee from Canonical that the intermediate > product works well together. Debian takes a different (and more stable) > approach and releases on features. They also have to corral a bunch of > separate components and make them work together. > > I would argue that the benefit of a release is that it's tested and > coherent. From a kafka standpoint I would rather see releases on > feature[set] with some testing and then have some notion of bug support for > a little while. If I want to have cutting edge or more frequent releases > then I should be able to grab stuff off of github and run that. > > > I don't agree that the benefits we're looking for are what we're going to > get. > > We can achieve some of the benefits listed without having to have timed > releases. What it seems you're looking for is more of a "heads up" > announcement that we plan to do a release. We could have a release process > that gives 4 weeks of warning. 2 weeks to get features in, 2 weeks of > freeze and then a release. There is no need to fix how often (and when) > this process happens. We just know that for a release to happen we'll have > 4 weeks advance notice. > > Nacho > > > > 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 >> > > > > -- > Nacho (Ignacio) Solis > nso...@linkedin.com -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
