I agree — but there are lots of people though who lag in adoption while waiting for more “risky” or “breaking” changes to shake out/stabilize that want to continue deploying newer fixes. No?
> On Jun 17, 2014, at 9:51 AM, Jake Luciani <jak...@gmail.com> wrote: > > I'm not sure many people have the problem you are describing. This is more > of a C* developer issue than a C* user issue. > > > Is the below what you are describing we move to?: > > 1.2 -> 2.0 -> 2.1 -> 3.0 stable > 1.2 <- 2.0 <- 2.1 <- 3.0 experimental > > Specific changes would be backported based on the "less riskyness" of the > change which you are assuming will be constant across versions? > > -Jake > > > > > On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman < > mkjell...@internalcircle.com> wrote: > >> It's a bit about features - but it's more an attempt to achieve the goals >> of what might happen with a 4 week release cycle (but that itself -- in >> practice didn't prove to be valid/reasonable). >> >> If something like an executor service for performance is changed (for >> example) it is definitely a more risky change than what would currently go >> into 1.2 -- but most likely we would want to get patches like that into a >> usable build. >> >> So I guess: a) reduce code drift between branches we run in production b) >> get newer "features" into production faster where breaking changes aren't >> required for the scope of the patch. >> >> Additionally - it's also a question of what release we use when we >> identify an issue we want to work on internally. If we are on 1.2 because >> we can't yet take ALL of 2.0 - do we now need to target our work against >> 1.2? I would rather write it against the months worth of changes that have >> happened since. >> >> Finally, it's an attempt to make the internal forking not as common as it >> might be today. As you said - this is somewhat of a common process. >> >>> On Jun 17, 2014, at 8:52 AM, "Jake Luciani" <jak...@gmail.com> wrote >>> >>> Hi Michael, >>> >>> I didn't get to hear the in person conversation so taking a step back. >>> The proposal seems to be in response to a common problem. i.e. I'm on >> C* >>> version X and I need feature Y which is only available on version Z. Is >>> this correct? >>> >>> The options have been: a) upgrade to version Z or b) fork C* and >> backport. >>> Coming my my previous job where I ran a prod C* cluster I felt this and I >>> expect many others do too. We did have to fork and backport patches we >>> needed and it was hard. >>> >>> This is specific to features and not bugs, since bugs are fixed in all >>> versions affected. >>> >>> -Jake >>> >>> >>> >>> >>> >>> >>> On Tue, Jun 17, 2014 at 3:16 AM, 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 >>> >>> >>> >>> >>> -- >>> http://twitter.com/tjake >> > > > > -- > http://twitter.com/tjake
