Regarding bug fixes, you may want to consider to have an LTS release once a year - designating it for longer-term support / better for the masses. If you like that - then fix bugs in trunk, backport important ones to latest release + the last two LTS releases. Even if you don't - if a downstream distribution picks a Kafka version and plans to support it over a few years, it could be nice of them to "own" that older release - volunteer to be a release manager for bug backports to that version over a longer period... Just my two cents :)
Ofir Manor Co-Founder & CTO | Equalum Mobile: +972-54-7801286 | Email: ofir.ma...@equalum.io On Thu, Aug 25, 2016 at 12:32 PM, Ismael Juma <ism...@juma.me.uk> wrote: > Thanks for putting this together Gwen. I think it sounds reasonable and > instead of trying to optimise every aspect of it ahead of time (which is > hard, subjective and time-consuming), I am happy to try what is being > proposed and tweak based on experience. One thing we should pay particular > attention to is how the stabilisation process works out in practice. > > A couple of comments: > > "Given 3 releases a year and the fact that no one upgrades three times a > year, we propose making sure (by testing!) that rolling upgrade can be done > from each release in the past year (i.e. last 3 releases) to the latest > version." > > Because the cost of doing this for a larger number of releases is > relatively low, I still think we should go for 6 here (our code currently > supports 5 versions as I said in a previous message, so we're close to that > target already). I'm generally very keen to make upgrades as easy as > possible so that people have no reason not to upgrade. :) > > "We will also attempt, as a community to do bugfix releases as needed for > the last 3 releases." > > I would suggest 2, personally, but since this is a bit fuzzy, I am OK with > 3 if people prefer that. > > Ismael > > On Thu, Aug 25, 2016 at 6:22 AM, Gwen Shapira <g...@confluent.io> wrote: > > > 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 > > >
