Re: cassandra-3.9 (and 3.8) release
Thanks for all the detail. I do appreciate your time in replying. I'm not fond of the idea of trying to cherry-pick trunk and delay further.. This has just been an odd and unorthodox moment in time to adopt release management, and I simply wish to do what's best for users. It's late, and I need to be up early for an event tomorrow. I'll build both releases Monday or sooner and get votes going. -- Michael On 09/24/2016 12:05 AM, Aleksey Yeschenko wrote: > Please don’t make me argue over 3.8/3.9 again. We are way, way over > 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 becomes the next 3.9, except it already has a ton of new > features, improvements, and a non-trivial amount of bugfixes as > well. > > We could branch off, and cherry-pick all the fixes back from trunk, > but just releasing both now is a lot less work. > > More importantly, it would mean delaying 3.9 by another month. We’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 upgrade > further. And the delta between 3.7 and current cassandra-3.9 is > pretty significant. Let’s not make people wait even longer, please? > > Plus, we had a consensus when this came up last time. Let’s stick to > the plan, because if we keep ignoring our previous conclusions we’ll > never release anything. > > (binding) -1 to (only) releasing the current cassandra-3.9 head as > 3.8. > > Michael: please start both votes. For 3.8 there is consensus, for 3.9 > there is consensus among PMCs. If something changed, it’ll be > reflected in the vote. > > -- AY > > On 23 September 2016 at 21:39:09, Michael Shuler > (mich...@pbandjelly.org) wrote: > > Jonathan's is a pretty compelling perspective. > > -- Michael > > On 09/23/2016 07:04 PM, Aleksey Yeschenko wrote: >> Both are effectively 3.9 on steroids. One month of features and >> improvements with 2 months of bug fixes on top. >> >> If anything, this overdelivers. >> >> -- AY >> >> On 23 September 2016 at 17:02:05, Jonathan Haddad >> (j...@jonhaddad.com) wrote: >> >> (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 >> 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 >>> >>> >> > >
Re: cassandra-3.9 (and 3.8) release
Please don’t make me argue over 3.8/3.9 again. We are way, way over 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 becomes the next 3.9, except it already has a ton of new features, improvements, and a non-trivial amount of bugfixes as well. We could branch off, and cherry-pick all the fixes back from trunk, but just releasing both now is a lot less work. More importantly, it would mean delaying 3.9 by another month. We’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 upgrade further. And the delta between 3.7 and current cassandra-3.9 is pretty significant. Let’s not make people wait even longer, please? Plus, we had a consensus when this came up last time. Let’s stick to the plan, because if we keep ignoring our previous conclusions we’ll never release anything. (binding) -1 to (only) releasing the current cassandra-3.9 head as 3.8. Michael: please start both votes. For 3.8 there is consensus, for 3.9 there is consensus among PMCs. If something changed, it’ll be reflected in the vote. -- AY On 23 September 2016 at 21:39:09, Michael Shuler (mich...@pbandjelly.org) wrote: Jonathan's is a pretty compelling perspective. -- Michael On 09/23/2016 07:04 PM, Aleksey Yeschenko wrote: > Both are effectively 3.9 on steroids. One month of features and > improvements with 2 months of bug fixes on top. > > If anything, this overdelivers. > > -- AY > > On 23 September 2016 at 17:02:05, Jonathan Haddad (j...@jonhaddad.com) > wrote: > > (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 > 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 >>> >> >> >
Re: cassandra-3.9 (and 3.8) release
Jonathan's is a pretty compelling perspective. -- Michael On 09/23/2016 07:04 PM, Aleksey Yeschenko wrote: > Both are effectively 3.9 on steroids. One month of features and > improvements with 2 months of bug fixes on top. > > If anything, this overdelivers. > > -- AY > > On 23 September 2016 at 17:02:05, Jonathan Haddad (j...@jonhaddad.com) > wrote: > > (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 > 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 >>> >> >> >
Re: cassandra-3.9 (and 3.8) release
Both are effectively 3.9 on steroids. One month of features and improvements with 2 months of bug fixes on top. If anything, this overdelivers. -- AY On 23 September 2016 at 17:02:05, Jonathan Haddad (j...@jonhaddad.com) wrote: (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 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 > > > >
Re: cassandra-3.9 (and 3.8) release
(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 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 > > > >
Re: cassandra-3.9 (and 3.8) release
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 >
Re: cassandra-3.9 (and 3.8) release
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
cassandra-3.9 (and 3.8) release
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