To add to what Gwen said (which makes sense to me), here's a link to the Cassandra release model:
http://www.planetcassandra.org/blog/cassandra-2-2-3-0-and-beyond/ It involves monthly releases, so more aggressive than what is being proposed, but they follow a tick tock model where a feature release is followed by a bug fix release (so a 2 months cycle for combined features + bug fixes, which is half the time than what is being proposed for Kafka). I also want to mention that the proposed model is likely to result in more effective testing than the previous model since we have a freeze period of similar duration, but a smaller period to accumulate changes. Ismael On Sat, Aug 13, 2016 at 3:02 AM, Gwen Shapira <g...@confluent.io> wrote: > 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 >
