No, it generally takes months to reach a minor revision of the current major release to reach a release stable enough for most to use in production even if they “live on the edge". Generally there ends up being a very low number of users who've actively deployed released versions 2.0.0-2.0.5 as they too need to evaluate the build and test it in their QA/Staging environments. There are plenty of changes that went into 2.0 that are less risky that are good changes for the “I’m living on the edge” crowd sans the breaking changes and larger risky factors. (I thought i had made this clear — so I apologize I apparently didn’t). Additionally, the longer we have to deploy releases from a particular branch (while a new “stable" branches matures), the farther that branch deviates from trunk. This makes it very hard for us to target development against, especially as we do everything in our power to avoid any sort of branching or running of a special or non-released build.
best, michael > On Jun 17, 2014, at 12:42 AM, Jacob Rhoden <jacob.rho...@me.com> wrote: > > 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
