Hi Gwen, The proposal sounds good to me. With regards to the cadence, 3 releases a year (every 4 months as you said) sounds reasonable. One thing that I think is very important if we release more often is that users should be able to upgrade directly to the latest release for a reasonable period. For example, we could say that we support direct upgrades for 2 years (6 releases).
Ismael On Wed, Aug 10, 2016 at 12:49 AM, Gwen Shapira <g...@confluent.io> wrote: > 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 >
