Exactly :) The goal is to have stable releases. We are hoping that time-based will help achieve this goal as well as introduce some stability to the planning process.
On Mon, Aug 15, 2016 at 12:55 PM, Nacho Solis <nso...@linkedin.com.invalid> wrote: > 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 -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
