kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gwen Shapira <g...@confluent.io>
Subject Re: [DISCUSS] Time-based releases for Apache Kafka
Date Thu, 25 Aug 2016 05:22:53 GMT
Hi Team Kafka,

As per the KIP meeting, I created a wiki:
Summarizing most of the discussion so far.

Comments and additional discussion is welcome :)


On Wed, Aug 17, 2016 at 12:31 PM, Vahid S Hashemian
<vahidhashemian@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 <gwen@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

View raw message