I prefer Ismael's suggestion for supporting 2-years (6 releases) rather than have designated LTS releases.
The LTS model seems to work well when some releases are high quality (LTS) and the rest are a bit more questionable. It is great for companies like Redhat, where they have to invest less to support few releases and let the community deal with everything else. Until now the Kafka community has managed to maintain very high quality level. Not just for releases, our trunk is often of better quality than other project's releases - we don't think of stability as something you tuck into a release (and just some releases) but rather as an on-going concern. There are costs to doing things that way, but in general, I think it has served us well - allowing even conservative companies to run on the latest released version. I hope we can agree to at least try maintaining last 6 releases as LTS (i.e. every single release is supported for 2 years) rather than designate some releases as better than others. Of course, if this totally fails, we can reconsider. Gwen On Thu, Aug 25, 2016 at 9:51 AM, Andrew Schofield <andrew_schofield_j...@outlook.com> wrote: > The proposal sounds pretty good, but the main thing currently missing is a > proper long-term support release. > > Having 3 releases a year sounds OK, but if they're all equivalent and bugfix > releases are produced for the most > recent 2 or 3 releases, anyone wanting to run on an "in support" release of > Kafka has to upgrade every 8-12 months. > If you don't actually want anything specific from the newer releases, it's > just unnecessary churn. > > Wouldn't it be better to designate one release every 12-18 months as a > long-term support release with bugfix releases > produced for those for a longer period of say 24 months. That halves the > upgrade work for people just wanting to keep > "in support". Now that adoption is increasing, there are plenty of users that > just want a dependable messaging system > without having to be deeply knowledgeable about its innards. > > LTS works nicely for plenty of open-source projects. I think it would work > well for Kafka too. > > Andrew Schofield > > ---------------------------------------- >> From: ofir.ma...@equalum.io >> Date: Thu, 25 Aug 2016 16:07:07 +0300 >> Subject: Re: [DISCUSS] Time-based releases for Apache Kafka >> To: dev@kafka.apache.org >> >> 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 >>>> >>> > -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
