Hi Team Kafka, As per the KIP meeting, I created a wiki: https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan Summarizing most of the discussion so far.
Comments and additional discussion is welcome :) Gwen On Wed, Aug 17, 2016 at 12:31 PM, Vahid S Hashemian <vahidhashem...@us.ibm.com> wrote: > Time-based releases is a good idea and something that has proved to be > working in a number of open source projects. One successful example is > Node.js, that goes through two major releases a year. The interesting fact > about the two releases is that only one (the even-number release) comes > with a long term support (LTS) plan (30 months). More can be read here: > https://github.com/nodejs/LTS. The odd-number releases still come with > major changes and help build the ecosystem, but as far as LTS goes, there > is only one per year. This LTS plan makes most enterprises want to stick > to even-number releases, which is okay since frequent upgrades is not > something they are normally interested in anyway. > > There could be several minor releases (non-breaking) in between major > releases. A major release contains all the features / bug fixes in the > master branch a month before the release date, with the potential addition > of (non-breaking) bug fixes until the release day. The deprecation cycle > is one major release: any functionality that is decided to be removed is > deprecated in the next major release, and removed in the major release > after that. > > Because of the success of LTS models in this and other open source > projects, I would suggest implementing a formal LTS plan for Kafka too. > > Regards, > --Vahid > > > > From: Gwen Shapira <g...@confluent.io> > To: dev@kafka.apache.org > Date: 08/09/2016 04:49 PM > Subject: [DISCUSS] Time-based releases for Apache Kafka > > > > Dear Kafka Developers and Users, > > In the past, our releases have been quite unpredictable. We'll notice > that a large number of nice features made it in (or are close), > someone would suggest a release and we'd do it. This is fun, but makes > planning really hard - we saw it during the last release which we > decided to delay by a few weeks to allow more features to "land". > > Many other communities have adopted time-based releases successfully > (Cassandra, GCC, LLVM, Fedora, Gnome, Ubuntu, etc.). And I thought it > will make sense for the Apache Kafka community to try doing the same. > > The benefits of this approach are: > > 1. A quicker feedback cycle and users can benefit from features > quicker (assuming for reasonably short time between releases - I was > thinking 4 months) > > 2. Predictability for contributors and users: > * Developers and reviewers can decide in advance what release they are > aiming for with specific features. > * If a feature misses a release we have a good idea of when it will show > up. > * Users know when to expect their features > > 3. Transparency - There will be a published cut-off date (AKA feature > freeze) for the release and people will know about it in advance. > Hopefully this will remove the contention around which features make > it. > > 4. Quality - we've seen issues pop up in release candidates due to > last-minute features that didn't have proper time to bake in. More > time between feature freeze and release will let us test more, > document more and resolve more issues. > > Since nothing is ever perfect, there will be some downsides: > > 1. Most notably, features that miss the feature-freeze date for a > release will have to wait few month for the next release. Features > will reach users faster overall as per benefit #1, but individual > features that just miss the cut will lose out > > 2. More releases a year mean that being a committer is more work - > release management is still some headache and we'll have more of > those. Hopefully we'll get better at it. Also, the committer list is > growing and hopefully it will be less than once-a-year effort for each > committer. > > 3. For users, figuring out which release to use and having frequent > new releases to upgrade to may be a bit confusing. > > 4. Frequent releases mean we need to do bugfix releases for older > branches. Right now we only do bugfix releases to latest release. > > I think the benefits outweigh the drawbacks. Or at least suggest that > its worth trying - we can have another discussion in few releases to > see if we want to keep it that way or try something else. > > My suggestion for the process: > > 1. We decide on a reasonable release cadence > 2. We decide on release dates (even rough estimate such as "end of > February" or something) and work back feature freeze dates. > 3. Committers volunteer to be "release managers" for specific > releases. We can coordinate on the list or on a wiki. If no committer > volunteers, we assume the community doesn't need a release and skip > it. > 4. At the "feature freeze" date, the release manager announces the > contents of the release (which KIPs made it in on time), creates the > release branch and starts the release process as usual. From this > point onwards, only bug fixes should be double-committed to the > release branch while trunk can start collecting features for the > subsequent release. > > Comments and improvements are appreciated. > > Gwen Shapira > Former-release-manager > > > > > -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
