Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 23 Sep 2016 22:05:41 -0700
From: Aleksey Yeschenko <aleksey@apache.org>
To: dev@cassandra.apache.org
Message-ID: <etPan.57e609a5.166eaf2c.44c@apache.org>
In-Reply-To: <eca60e66-deff-2188-860c-ecd9e1757ce9@pbandjelly.org>
References: <f76ec9d6-b99f-7677-afe2-d425bad88e4f@pbandjelly.org>
 <etPan.57e5a993.3e254480.44c@apache.org>
 <08fbb3a9-165f-0d0c-8874-ecdeeb6a85d9@pbandjelly.org>
 <CACUnPaB-Wft6Bf-FnP3X3wTdOHN4hKvppC6nM-WDR1EcM0jhUQ@mail.gmail.com>
 <etPan.57e5c309.605069ba.44c@apache.org>
 <eca60e66-deff-2188-860c-ecd9e1757ce9@pbandjelly.org>
Subject: Re: cassandra-3.9 (and 3.8) release
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="57e609a5_77b2c561_44c"
archived-at: Sat, 24 Sep 2016 05:05:51 -0000

--57e609a5_77b2c561_44c
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Please don=E2=80=99t make me argue over 3.8/3.9 again. We are way, way ov=
er our original schedule at this point.

Releasing 3.9 now breaks no promises. You still get more than a month of =
purely bug fixes in the release.

And if we only do 3.8 off the current cassandra-3.9 branch, then trunk be=
comes the next 3.9,
except it already has a ton of new features, improvements, and a non-triv=
ial amount of bugfixes as well.

We could branch off, and cherry-pick all the fixes back from trunk, but j=
ust releasing both now is a lot less work.

More importantly, it would mean delaying 3.9 by another month. We=E2=80=99=
ve communicated that odd ones are to be run in production,
so users stuck on 3.7 would have to wait even longer until the can upgrad=
e further. And the delta between 3.7 and current cassandra-3.9
is pretty significant. Let=E2=80=99s not make people wait even longer, pl=
ease=3F

Plus, we had a consensus when this came up last time. Let=E2=80=99s stick=
 to the plan, because if we keep ignoring our
previous conclusions we=E2=80=99ll never release anything.

(binding) -1 to (only) releasing the current cassandra-3.9 head as 3.8.

Michael: please start both votes. =46or 3.8 there is consensus, for 3.9 t=
here is consensus among PMCs. If something changed,
it=E2=80=99ll be reflected in the vote.

--=C2=A0
AY

On 23 September 2016 at 21:39:09, Michael Shuler (michael=40pbandjelly.or=
g) wrote:

Jonathan's is a pretty compelling perspective. =20

-- =20
Michael =20

On 09/23/2016 07:04 PM, Aleksey Yeschenko wrote: =20
> Both are effectively 3.9 on steroids. One month of features and =20
> improvements with 2 months of bug fixes on top. =20
> =20
> If anything, this overdelivers. =20
> =20
> -- AY =20
> =20
> On 23 September 2016 at 17:02:05, Jonathan Haddad (jon=40jonhaddad.com)=
 =20
> wrote: =20
> =20
> (non-binding) -1 on releasing 2 versions with the same version =20
> number. Everything that's been communicated to the world has been =20
> that there would be a feature release, then a bug fix release a month =20
> later. This breaks that promise. =20
> =20
> On =46ri, Sep 23, 2016 at 4:23 PM Michael Shuler =20
> <michael=40pbandjelly.org> wrote: =20
> =20
>> Thanks=21 I'll do these release builds and start votes, first thing =20
>> Monday morning, unless I find some time on Sunday. =20
>> =20
>> -- Michael =20
>> =20
>> On 09/23/2016 05:15 PM, Aleksey Yeschenko wrote: =20
>>> Branch 3.8 off 3.9 with a commit that only changes the version in =20
>>> all =20
>> appropriate places. =20
>>> =20
>>> Two separate votes works. =20
>>> =20
>>> -- AY =20
>>> =20
>>> On 23 September 2016 at 12:36:54, Michael Shuler =20
>>> (michael=40pbandjelly.org) =20
>> wrote: =20
>>> =20
>>> The cassandra-3.9 branch HEAD, commit bb371ea, looks good to =20
>>> release (which will also be released as 3.8, changing just the =20
>>> version number). I'm re-running a couple jobs right now, but =20
>>> overall, I think we hit the goal of a clean board: =20
>>> http://cassci.datastax.com/view/cassandra-3.9/ =20
>>> =20
>>> If there are no objections, I'd like to roll up 3.9/3.8 and get =20
>>> them out the door. Should this be on one vote, since they are =20
>>> really the same, or do 2 votes=3F I'm actually not entirely sure =20
>>> how the build for 3.8 will work, since the branch was deleted. =20
>>> Should I create new branch again for 3.8 with the version edit=3F =20
>>> This sounds the most reasonable and workable with the release =20
>>> build process. This actually does sound like it should be 2 =20
>>> votes, since the commit sha will be different.. Thanks=21 =20
>>> =20
>>> -- Kind regards, Michael =20
>>> =20
>> =20
>> =20
> =20


--57e609a5_77b2c561_44c--