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
