Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of jacob.rhoden@me.com
 designates 17.158.232.236 as permitted sender)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Subject: Re: Proposed changes to C* Release Schedule
References: <007B9AF3-36E4-4387-8CED-A0466F188E53@internalcircle.com>
From: Jacob Rhoden <jacob.rhoden@me.com>
In-reply-to: <007B9AF3-36E4-4387-8CED-A0466F188E53@internalcircle.com>
Message-id: <8DDE7723-1A25-4CC3-A6B3-07F1D0AF9497@me.com>
Date: Tue, 17 Jun 2014 17:42:33 +1000
To: "dev@cassandra.apache.org" <dev@cassandra.apache.org>
Content-transfer-encoding: quoted-printable

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=20

______________________________
Sent from iPhone

> On 17 Jun 2014, at 5:16 pm, Michael Kjellman <mkjellman@internalcircle.com=
> wrote:
>=20
> Hi Dev@ List=E2=80=94
>=20
> TL;DR:
> I=E2=80=99d love it if we could modify the C* release cycle to include an a=
dditional =E2=80=9Cexperimental=E2=80=9D release branch that straddles the c=
urrent major releases that includes somewhat =E2=80=9Cuntested=E2=80=9D or =E2=
=80=9Crisky=E2=80=9D commits that normally would only go into the next major=
 release. Releases based from this branch wouldn=E2=80=99t contain any featu=
res that require breaking changes or are considered highly =E2=80=9Cuntested=
=E2=80=9D or =E2=80=9Crisky=E2=80=9D but would include the many other commit=
s that today are considered too unsafe to put into the previous stable branc=
h. This will allow us to run code closer to the current stable release branc=
h when we are unable to move fully to the new major release branch. Also, du=
ring the release cycle of the next major release branch the project can get f=
eedback from a subset of the total changes that will ultimately make it into=
 that final new major release. Also =E2=80=94 i=E2=80=99m aware that any add=
itional branches/releases will add additional work for any developer that wo=
rks on C*. It would be great if we could strike a balance that hopefully doe=
sn=E2=80=99t add significant additional merging/rebasing/work for the team..=
.
>=20
> The Longer Story:
> Last week I had a conversation with a few people regarding a proposed chan=
ge to the current C* release schedule.=20
>=20
> Other than an attempt to make Jonathan and Sylvian=E2=80=99s lives more di=
fficult, it would be ideal if we could better sync our internal release sche=
dule with more recent Cassandra releases. The current cycle has resulted in c=
urrently =E2=80=9Cactive=E2=80=9D branches for 1.2, 2.0, 2.1, and +3.0. Offi=
cial stable releases are from 2.0, beta=E2=80=99s/RC=E2=80=99s from 2.1, and=
 there is the potential for another out-of-band 1.2/previous stable release b=
uild. We would love to always run the current =E2=80=9Cstable=E2=80=9D relea=
se in production but generally/historically it takes time and a few minor re=
leases to the current =E2=80=9Cmajor=E2=80=9D branch stable to get to a stat=
e where we can accept for use in production. Additionally, as major releases=
 are currently used to make =E2=80=9Cbreaking=E2=80=9D changes that require a=
 more involved and risky upgrade process, it=E2=80=99s 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 rel=
ease branch. this unavoidable step adds lots of temporary load to the cluste=
r and means deploying/upgrading to major releases tends to be a bit more ris=
ky than between minor releases and a more involved/long running process). Th=
is means even though there are months worth of stable hard work/awesome impr=
ovements in the current =E2=80=9Cstable=E2=80=9D major release branch (today=
 this is 2.0), we end up with an unavoidable and undesired lag in getting mo=
re recent C* changes pushed into production. This means we are unable to pro=
vide feedback on newer changes sooner to the community, stuck and unable to g=
et even a subset of the awesome changes as we can=E2=80=99t yet take ALL the=
 changes from the new major release branch, and finally if we find an issue i=
n production or want to work on new functionality it would be ideal if we ca=
n write it against a release that is closer to the next major release while a=
lso providing us a reasonable way to get the feature deployed internally on a=
 branch we are running.
>=20
> Currently, the project generally tends to include all risky/breaking/more =E2=
=80=9Cfeature=E2=80=9D oriented tickets only into the next major release + t=
runk. However, there is a subset of these changes that are =E2=80=9Csomewhat=
=E2=80=9D more risky changes but pose little/less/no risk the commit with in=
troduce a regression outside of the scope of the patch/component. Additional=
ly, any changes that  depend on other higher risk/breaking commits/changes w=
ouldn=E2=80=99t be candidates for this proposed release branch. In a perfect=
 world we would love to target a new =E2=80=9Cinterim=E2=80=9D or =E2=80=9Ce=
xperimental=E2=80=9D train of releases which is loosely the most stable curr=
ent release train but also includes a subset of changes from the next major t=
rain. (While we were discussing we thought about possible parallels to the c=
oncept of a LTS (Long Term Support) release cycle and what some people have d=
ubbed the =E2=80=9Ctick-tock=E2=80=9D release cycle.) This might look someth=
ing like 1.2 branch + all moderately-to-=E2=80=9Cless=E2=80=9D-risky/non-bre=
aking commits which currently would only end up in a 2.0 or 2.1 release. (Of=
f 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 t=
he storage format etc). This would enable the project to provide builds for m=
ore active/risk-adverse users looking for a reasonable way to get more featu=
res and changes into production than with today=E2=80=99s release cycle. Add=
itionally, this would hopefully facilitate/increase quicker feedback to the p=
roject on a subset of the new major release branch and any bugs found could b=
e reported against an actual reproducible release instead of some custom bui=
ld with a given number of patches from Jira or git SHAs applied/backported.
>=20
> As it will always take both time and n releases to reach a stable minor re=
lease for a new major train; users could deploy this new release to get a su=
bset of new features and changes with higher risk than would otherwise go in=
to a minor release of the previous stable release train. If internally we wa=
nted to add a new feature we could target this release while testing interna=
lly, and hopefully given the smaller delta between this =E2=80=9Cinterim/exp=
erimental=E2=80=9D to make it easier to re-base patches into the next major r=
elease 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 a=
ttempt to sync our internal releases with a internally/or community QA=E2=80=
=99ed/accepted build/release of the current =E2=80=9Cstable=E2=80=9D build/b=
ranch (currently this is 2.0).
>=20
> To accomplish this, the commit workflow would unfortunately need change wh=
ere an additional process is added to determine =E2=80=9Celigibility=E2=80=9D=
 or =E2=80=9Cappropriateness=E2=80=9D of a given commit to additionally also=
 be committed to the =E2=80=9Cexperimental=E2=80=9D build branch (maybe it=E2=
=80=99s as simple as leaving it up to the reviewer + author to determine the=
 risk factor and difficulty in merging the change back into the =E2=80=9Cexp=
erimental=E2=80=9D build?). If it is agreed the commit/change/patch is a goo=
d candidate for the =E2=80=9Cexperimental=E2=80=9D branch, in addition to co=
mmitting the patch to the current major release branch, the commit would als=
o be merged into the new =E2=80=9Cexperimental=E2=80=9D release. If commits m=
ake it into the =E2=80=9Cexperimental=E2=80=9D branch frequently, I would ex=
pect/hope merging patches into the =E2=80=9Cexperimental=E2=80=9D build woul=
d be relatively easy as the =E2=80=9Cexperimental=E2=80=9D branch should als=
o have most of the changes from the major release branch sans those consider=
ed 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 o=
ur code against the =E2=80=9Cexperimental=E2=80=9D branch, allowing us to te=
st our changes in production without forking C* internally, writing our code=
 against more recent =E2=80=9Cmodern=E2=80=9D changes, and then hopefully ge=
tting that work back to the community.
>=20
>=20
> Hope this was clear enough and accurately summarizes the conversation a fe=
w of us had! Looking forward to everyone=E2=80=99s feedback and comments.
>=20
> best,
> kjellman