Isn't this how it works now? Aka 2.0 is the "I'm risk averse" stable, and 2.1 is the "I'm living on the edge" stable
______________________________ Sent from iPhone > On 17 Jun 2014, at 5:16 pm, Michael Kjellman <mkjell...@internalcircle.com> > wrote: > > Hi Dev@ List— > > TL;DR: > I’d love it if we could modify the C* release cycle to include an additional > “experimental” release branch that straddles the current major releases that > includes somewhat “untested” or “risky” commits that normally would only go > into the next major release. Releases based from this branch wouldn’t contain > any features that require breaking changes or are considered highly > “untested” or “risky” but would include the many other commits that today are > considered too unsafe to put into the previous stable branch. This will allow > us to run code closer to the current stable release branch when we are unable > to move fully to the new major release branch. Also, during the release cycle > of the next major release branch the project can get feedback from a subset > of the total changes that will ultimately make it into that final new major > release. Also — i’m aware that any additional branches/releases will add > additional work for any developer that works on C*. It would be great if we > could strike a balance that hopefully doesn’t add significant additional > merging/rebasing/work for the team... > > The Longer Story: > Last week I had a conversation with a few people regarding a proposed change > to the current C* release schedule. > > Other than an attempt to make Jonathan and Sylvian’s lives more difficult, it > would be ideal if we could better sync our internal release schedule with > more recent Cassandra releases. The current cycle has resulted in currently > “active” branches for 1.2, 2.0, 2.1, and +3.0. Official stable releases are > from 2.0, beta’s/RC’s from 2.1, and there is the potential for another > out-of-band 1.2/previous stable release build. We would love to always run > the current “stable” release in production but generally/historically it > takes time and a few minor releases to the current “major” branch stable to > get to a state where we can accept for use in production. Additionally, as > major releases are currently used to make “breaking” changes that require a > more involved and risky upgrade process, it’s a much bigger deal to deploy a > new major into production than a release without breaking changes. > (upgrade-sstables for example is required when upgrading to a new major > release branch. this unavoidable step adds lots of temporary load to the > cluster and means deploying/upgrading to major releases tends to be a bit > more risky than between minor releases and a more involved/long running > process). This means even though there are months worth of stable hard > work/awesome improvements in the current “stable” major release branch (today > this is 2.0), we end up with an unavoidable and undesired lag in getting more > recent C* changes pushed into production. This means we are unable to provide > feedback on newer changes sooner to the community, stuck and unable to get > even a subset of the awesome changes as we can’t yet take ALL the changes > from the new major release branch, and finally if we find an issue in > production or want to work on new functionality it would be ideal if we can > write it against a release that is closer to the next major release while > also providing us a reasonable way to get the feature deployed internally on > a branch we are running. > > Currently, the project generally tends to include all risky/breaking/more > “feature” oriented tickets only into the next major release + trunk. However, > there is a subset of these changes that are “somewhat” more risky changes but > pose little/less/no risk the commit with introduce a regression outside of > the scope of the patch/component. Additionally, any changes that depend on > other higher risk/breaking commits/changes wouldn’t be candidates for this > proposed release branch. In a perfect world we would love to target a new > “interim” or “experimental” train of releases which is loosely the most > stable current release train but also includes a subset of changes from the > next major train. (While we were discussing we thought about possible > parallels to the concept of a LTS (Long Term Support) release cycle and what > some people have dubbed the “tick-tock” release cycle.) This might look > something like 1.2 branch + all moderately-to-“less”-risky/non-breaking > commits which currently would only end up in a 2.0 or 2.1 release. (Off the > top of my head, immediately bad candidates for this build would be for > changes to components such as gossip, streaming, or any patch that changes > the storage format etc). This would enable the project to provide builds for > more active/risk-adverse users looking for a reasonable way to get more > features and changes into production than with today’s release cycle. > Additionally, this would hopefully facilitate/increase quicker feedback to > the project on a subset of the new major release branch and any bugs found > could be reported against an actual reproducible release instead of some > custom build with a given number of patches from Jira or git SHAs > applied/backported. > > As it will always take both time and n releases to reach a stable minor > release for a new major train; users could deploy this new release to get a > subset of new features and changes with higher risk than would otherwise go > into a minor release of the previous stable release train. If internally we > wanted to add a new feature we could target this release while testing > internally, and hopefully given the smaller delta between this > “interim/experimental” to make it easier to re-base patches into the next > major release train. This would help us avoid what today has unfortunately > become a unavoidable large lag in getting new C* builds into production as > while we attempt to sync our internal releases with a internally/or community > QA’ed/accepted build/release of the current “stable” build/branch (currently > this is 2.0). > > To accomplish this, the commit workflow would unfortunately need change where > an additional process is added to determine “eligibility” or > “appropriateness” of a given commit to additionally also be committed to the > “experimental” build branch (maybe it’s as simple as leaving it up to the > reviewer + author to determine the risk factor and difficulty in merging the > change back into the “experimental” build?). If it is agreed the > commit/change/patch is a good candidate for the “experimental” branch, in > addition to committing the patch to the current major release branch, the > commit would also be merged into the new “experimental” release. If commits > make it into the “experimental” branch frequently, I would expect/hope > merging patches into the “experimental” build would be relatively easy as the > “experimental” branch should also have most of the changes from the major > release branch sans those considered highly risky or breaking. Additionally, > if internally we want to work on a new feature and test internally before > submitting a patch, we could target our code against the “experimental” > branch, allowing us to test our changes in production without forking C* > internally, writing our code against more recent “modern” changes, and then > hopefully getting that work back to the community. > > > Hope this was clear enough and accurately summarizes the conversation a few > of us had! Looking forward to everyone’s feedback and comments. > > best, > kjellman
