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
