To clear up, I'm not against time-based releases, I just think that the goals that were stated are not intrinsic to time-based releases but the release process (whether it's time-based or not).
The goal of "when will my code get into a release" and the goal of getting features faster in a release (vs just in trunk) seem (imho) secondary to providing stable releases. If the releases happen every 4 months then we're saying every 4 months we're providing a stable release, right? Nacho On Sat, Aug 13, 2016 at 12:17 PM, Neha Narkhede <n...@confluent.io> wrote: > I'm supportive of this for 2 reasons - > > 1. The community has been looking for predictability and this allows us to > offer that to Kafka users > 2. Trunk stability and the ability to release from trunk. This is important > for several companies and more frequent releases means higher quality and > faster detection of regressions. > > This does mean we are signing up for more work in the following areas -- > > 1. Release management by committers. > 2. Discipline amongst contributors to pull put features that are not ready > by the code freeze. > > We'd also have to learn what cadence works for Kafka. We can start with the > one that Gwen suggested and see what works. > > I'd give it a try. > On Sat, Aug 13, 2016 at 11:25 AM Kartik Paramasivam > <kparamasi...@linkedin.com.invalid> wrote: > > > 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 > > >> > > > -- Nacho (Ignacio) Solis nso...@linkedin.com
