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