I hear what you are saying (enterprises upgrade every 2-years more-or-less). It seems reasonable - this basically means maintaining 10 compatibility tests at any point in time. We will need to be disciplined about maintaining those tests though - or it will get painful.
Another thing, hurrying up with implementing full forward-and-back compatibility for clients (i.e. full KIP-35 support in clients) would go a long way toward making upgrades less painful. Gwen On Wed, Aug 10, 2016 at 6:34 AM, Ismael Juma <ism...@juma.me.uk> wrote: > 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 >> -- Gwen Shapira Product Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
