Re: Wrapping up tick-tock

+1 to 6 months *major* release. I think we still need *minor* release containing bug fixes (or small features maybe?), which I think would make sense to release more frequently, like monthly. So that we won't need to wait for 6 months for bug fixes, or have to maintain a lot of patches internally.

Re: Rollback procedure for Cassandra Upgrade.

On Tuesday, January 10, 2017, Romain Hardouin wrote: > To be able to downgrade we should be able to pin both commitlog and > sstables versions, e.g. -Dcassandra.commitlog_version=3 > -Dcassandra.sstable_version=jb > That would be awesome because it would decorrelate binaries version and > data ve

Re: Wrapping up tick-tock

+1 to 6 month release and ending tick/tock On Tue, Jan 10, 2017 at 9:44 AM, Nate McCall wrote: > > > > If this question is to outside the topic and more appropriate for a > > different thread I'm happy to put a hold on it until the release cadence > is > > agreed. > > > > Let's please do put thi

Re: Per blockng release on dtest

+1 On Tue, Jan 10, 2017 at 9:23 AM, Aleksey Yeschenko wrote: > That’s a good point. > > So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? > > +1 to that. > > -- > AY > > On 10 January 2017 at 17:22:09, Michael Shuler (mich...@pbandjelly.org) > wrote: > > I had the same though

Re: Wrapping up tick-tock

> > If this question is to outside the topic and more appropriate for a > different thread I'm happy to put a hold on it until the release cadence is > agreed. > Let's please do put this on another thread. Thanks for bringing it up though as it is important and needs discussion.

Re: Wrapping up tick-tock

+1 on killing tick/tock +1 on six months What is the appetite for a longer bug fix period for some releases (e.g. every second release gets 18 - 24 months critical bug fixes)? Currently only vendors / large users are maintaining long running releases, given this work is already happening I would

Re: Per blockng release on dtest

> > So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? > +1

Re: Per blockng release on dtest

+1 On Tue, Jan 10, 2017 at 11:23 AM, Aleksey Yeschenko wrote: > That’s a good point. > > So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? > > +1 to that. > > -- > AY > > On 10 January 2017 at 17:22:09, Michael Shuler (mich...@pbandjelly.org) > wrote: > > I had the same though

Re: Wrapping up tick-tock

> I agreed with you at the time that the yearly cycle was too long to be > adding features before cutting a release, and still do now. Instead of > elastic banding all the way back to a process which wasn't working before, > why not try somewhere in the middle? A release every 6 months (with > mo

Re: Per blockng release on dtest

> So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? +1 On Tue, Jan 10, 2017 at 12:23 PM, Aleksey Yeschenko wrote: > That’s a good point. > > So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? > > +1 to that. > > -- > AY > > On 10 January 2017 at 17:22:09, Mich

Re: Per blockng release on dtest

That’s a good point. So 3.11 after 3.10, then move on to 3.11.x further bug fix releases? +1 to that. --  AY On 10 January 2017 at 17:22:09, Michael Shuler (mich...@pbandjelly.org) wrote: I had the same thought. 3.10 is the tick, so a 3.11 bugfix tock follows the intended final fix release f

Re: Per blockng release on dtest

I had the same thought. 3.10 is the tick, so a 3.11 bugfix tock follows the intended final fix release for closing out tick-tock. Throwing a 3.10.1 out there would add more user confusion and would be the exact same contents as a 3.11 release versioned package set anyway. -- Michael On 01/10/201

Re: Per blockng release on dtest

> Seems like we'd just release that as 3.10.1 (instead of 3.11) and just > tell people "you can upgrade to 4.0 w/latest version of 3.10". This > does violate the "even releases features, odd releases bugfix", so > maybe a 3.11 as final 3.X line would help keep that consistent? This feels like a de

Re: Per blockng release on dtest

| If someone tries to upgrade 3.10 to whatever 4.0 ends up being I think they will hit the wrong answer bug. So I would advocate for having the fix brought into 3.10, but it was broken in 3.9 as well. Seems like we'd just release that as 3.10.1 (instead of 3.11) and just tell people "you can upgra

Re: Per blockng release on dtest

Hi, The upgrade tests are tricky because they upgrade from an existing release to a current release. The bug is in 3.9 and won't be fixed until 3.11 because the test checks out and builds 3.9 right now. 3.10 doesn't include the commit that fixes the issue so it will fail after 3.10 is released

Re: Per blockng release on dtest

I would personally favour pushing 3.10 out without waiting for the pretty innocent #13113 resolution. With the amount of bug fixes accumulated in the 3.X branch it’s borderline irresponsible to not release them out to the users. --  AY On 10 January 2017 at 17:05:57, Michael Shuler (mich...@pba

Re: Per blockng release on dtest

Generally, fixver has only been set during commits - I only marked 3.10 and blocker status to highlight the few that failed votes, in order to sort of cheerlead "fix me so we can release!" JIRA tickets. The full test-failure list is probably the more "realistic" view, since any of those may occur.

Re: Per blockng release on dtest

Latest cassandra-3.11_dtest run failed on one test, system_auth_ks_is_alterable_test: https://issues.apache.org/jira/browse/CASSANDRA-13113 The dtest variations (novnode, offheap, upgrade, large) have other failures, but if the green light for release is unit tests and the default dtest, we're cl

Re: Per blockng release on dtest

I assume you meant the query w/out 12617 embedded? https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%203.10%20AND%20resolution%20%3D%20Unresolved Do we have confidence that all test failures have fixVersion attached correctly? The list of test failures w

Re: Per blockng release on dtest

> > I concede it would be fine to do it gradually. Once the pace of issues > introduced by new development is beaten by the pace at which they are > addressed I think things will go well. So from Michael's JIRA query: https://issues.apache.org/jira/browse/CASSANDRA-12617?jql=project%20%3D%20CASSAN

Re: Wrapping up tick-tock

I’m thinking put it on the same rails as 2.2.x and 3.0.x. As needed. --  AY On 10 January 2017 at 16:46:25, Josh McKenzie (jmcken...@apache.org) wrote: > > I would also propose we move on to 3.10.x bugfix only releases from now > on, with all new feature development moving to trunk from now

Re: Wrapping up tick-tock

> > I would also propose we move on to 3.10.x bugfix only releases from now > on, with all new feature development moving to trunk from now on. You thinking monthly release on that or "as needed"? In theory, monthly should be easier than previous tick-tock if we're only putting in bugfix or testfi

Re: Wrapping up tick-tock

6 months seems reasonable to me as well. There seems to be an agreement to halting 3.X on 3.10. I would also propose we move on to 3.10.x bugfix only releases from now on, with all new feature development moving to trunk from now on. This should allow us to finally stabilise 3.X so that we can ge

Re: Wrapping up tick-tock

+1 to 6 months. On Tue, Jan 10, 2017 at 11:32 AM, Jonathan Ellis wrote: > I agree that 6 month seems like a reasonable compromise. > > On Tue, Jan 10, 2017 at 10:31 AM, Blake Eggleston > wrote: > > > I agree that 3.10 should be the last tick-tock release, but I also agree > > with Jon that we s

Re: Wrapping up tick-tock

I agree that 6 month seems like a reasonable compromise. On Tue, Jan 10, 2017 at 10:31 AM, Blake Eggleston wrote: > I agree that 3.10 should be the last tick-tock release, but I also agree > with Jon that we shouldn't go back to yearly-ish releases. > > 6 months has come up several times now as

Re: Wrapping up tick-tock

The problem with long release cycles is that everything goes in. and you have potentially a mish-mash of features, some more done than others, causing instability. Quick releases attempt to fix this issue by keeping the number of commits down to a manageable size. The problem is that that commi

Re: Wrapping up tick-tock

I agree that 3.10 should be the last tick-tock release, but I also agree with Jon that we shouldn't go back to yearly-ish releases. 6 months has come up several times now as a good cadence for feature releases, and I think it's a good compromise between the competing interests of long term supp

Re: Per blockng release on dtest

Hi, I concede it would be fine to do it gradually. Once the pace of issues introduced by new development is beaten by the pace at which they are addressed I think things will go well. Ariel On Tue, Jan 10, 2017, at 11:17 AM, Josh McKenzie wrote: > @ariel: you're letting the perfect be the enemy

Re: Per blockng release on dtest

If they aren’t regressions from 3.9, we should still push 3.10 out. The branch has accumulated a lot of fixes, for problems that *are* real. Just have a look at CHANGES.txt. By holding 3.10 you are denying those (arguably few, but still) users fixes for bugs that we know are in. It’s been more

Re: Per blockng release on dtest

@ariel: you're letting the perfect be the enemy of the good here. We (as a project) have been releasing with a smattering of test failures and upgrade edge-cases back into perpetuity. While that doesn't make it ideal or justify continuing the behavior, getting a green testall + dtest for 3.10 is a

Re: Wrapping up tick-tock

Hi, With yearly releases trunk is going to be a mess when it comes time to cut a release. Cutting releases is when people start caring whether all the things in the release are in a finished state. It's when the state of CI finally becomes relevant. If we wait a year we are going to accumulate a

Re: Per blockng release on dtest

Hi, At least some of those failures are real. I don't think we should release 3.10 until the real failures are addressed. As I said earlier one of them is a wrong answer bug that is not going to be fixed in 3.10. Can we just ignore failures because we think they don't mean anything? Who is going

Re: Wrapping up tick-tock

I don't see why it has to be one extreme (yearly) or another (monthly). When you had originally proposed Tick Tock, you wrote: "The primary goal is to improve release quality. Our current major “dot zero” releases require another five or six months to make them stable enough for production. This

Wrapping up tick-tock

Hi all, We’ve had a few threads now about the successes and failures of the tick-tock release process and what to do to replace it, but they all died out without reaching a robust consensus. In those threads we saw several reasonable options proposed, but from my perspective they all operated in

Re: Per blockng release on dtest

I think we should start with blocking 3.10 releases on testall + Dtest. After 3.10, we can start blocking it on other jobs for each release after that. This will make sure we make progress and dont cause 3.10 to sit for a long time. Thoughts? On Tue, Jan 10, 2017 at 5:13 AM, Josh McKenzie wrote:

Re: Per blockng release on dtest

First, I think we need to clarify if we're blocking on just testall + dtest or blocking on *all test jobs*. If the latter, upgrade tests are the elephant in the room: http://cassci.datastax.com/view/cassandra-3.11/job/cassandra-3.11_dtest_upgrade/lastCompletedBuild/testReport/ Do we have confiden

Re: Rollback procedure for Cassandra Upgrade.

See the comment thread on https://issues.apache.org/jira/browse/CASSANDRA-8928 (add downgradesstables) > On Jan 10, 2017, at 5:00 AM, Jonathan Haddad wrote: > > There's no downgrade procedure. You either upgrade or you go back to a > snapsho

Re: Rollback procedure for Cassandra Upgrade.

To be able to downgrade we should be able to pin both commitlog and sstables versions, e.g. -Dcassandra.commitlog_version=3 -Dcassandra.sstable_version=jb That would be awesome because it would decorrelate binaries version and data version. Upgrades would be much less risky so I guess that adopti