I'm +1. I've seen this both ways and I really do think that time-based releases tend to scale better with more developers doing parallel work (I think the probability of at least one feature slipping as you have more and more developers gets very high, and if that means the release slips then the release will frequently slip quite a lot). I think between the clients, the server, streams, connect, etc there is enough parallelism that this will be important.
I think this also gives a lot more predictability to people who contribute code or want to use a feature they see on trunk as to when it will be available in a release (to date our answer has been "eventually", which is a bit unsatisfying). -Jay On Tue, Aug 9, 2016 at 4:49 PM, 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 >
