> 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 <alek...@apache.org> 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 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. >>> >>> >
