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 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/2017 11:18 AM, Josh McKenzie wrote: > | 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 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? > > I'd rather not open the can of worms of back-porting this to 3.9 as > well to hold to our claim of "any 3.X can go to 4.0". > > On Tue, Jan 10, 2017 at 12:13 PM, Ariel Weisberg <ar...@weisberg.ws> wrote: >> 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 and the test is updated to check out 3.10. >> >> >> We claim to support upgrade from any 3.x version to 4.0. 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. >> >> >> Some of the tests fail because trunk complains of unreadable stables and >> I suspect that isn't a bug it's just something that is no longer >> supported due to thrift removal, but I haven't fixed those yet. Those >> are probably issues with trunk or the tests. >> >> >> Others fail for reasons I haven't triaged yet. I'm struggling with my >> own issues getting the tests to run locally. >> >> >> Ariel >> >> >> >> On Tue, Jan 10, 2017, at 11:49 AM, Nate McCall wrote: >> >>>> >> >>>> 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%20CASSANDRA%20AND%20fixVersion%20%3D%203.10%20AND%20resolution%20%3D%20Unresolved >>> >>> >> >>> Are we good for 3.10 after we get those cleaned up? >> >>> >> >>> Ariel, you made reference to: >> >>> https://github.com/apache/cassandra/commit/c612cd8d7dbd24888c216ad53f974686b88dd601 >>> >>> >> >>> Do we need to re-open an issue to have this applied to 3.10 and add it >>> to the above list? >> >>> >> >>>> >> >>>> On Tue, Jan 10, 2017, at 11:17 AM, Josh McKenzie wrote: >> >>>>> >> >>>>> Sankalp's proposal of us progressively tightening up our standards >>>>> allows >>>>> us to get code out the door and regain some lost momentum on >>>>> the 3.10 >>>>> release failures and blocking, and gives us time as a community to >>>>> adjust >>>>> our behavior without the burden of an ever-later slipped release >>>>> hanging >>>>> over our heads. There's plenty of bugfixes in the 3.X line; the >>>>> more time >>>>> people can have to kick the tires on that code, the more things >>>>> we can >>>>> find >> >>>>> and the better future releases will be. >> >>> >> >>> >> >>> +1 On gradually moving to this. Dropping releases with huge change >> >>> lists has never gone well for us in the past. >> >>
