+1 On Tue, Jan 10, 2017 at 11:23 AM, 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. > >> > >> > > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
