Plus one. This is a good direction to move towards. The frequency of releases would probably depend on how long it takes to certify the release.
> On Aug 13, 2016, at 10:18 AM, Jay Kreps <j...@confluent.io> wrote: > > 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 >>
