Before we blanket update all of these, let's make sure they are not relevant for 4.0 - because some of them actually are. Some are docs, some are parent tickets, some are testing.
Naively, here are some that are still 4.0: CASSANDRA-14746 <https://issues.apache.org/jira/browse/CASSANDRA-14746> CASSANDRA-13254 <https://issues.apache.org/jira/browse/CASSANDRA-13254> CASSANDRA-14606 <https://issues.apache.org/jira/browse/CASSANDRA-14606> Thanks, -Jason On Tue, Sep 25, 2018 at 4:05 AM, Benedict Elliott Smith <bened...@apache.org > wrote: > Do we want to manage more versions than we do now? Why don’t we simply > align these things to majors, like we’ve typically tried to anyway? > > I think it’s anyway better to decide on a strategy and find a versioning > scheme that matches it, rather than to look for a strategy that matches our > current versioning scheme. > > > > > > On 25 Sep 2018, at 03:07, Mick Semb Wever <m...@apache.org> wrote: > > > > > > > > > >> I'm totally spitballing here on possible uses of meaningful minors. > > > > Continuing the splitballing… > > > > What about aligning native protocol or sstable format changes with the > minor version? > > > > > >> Regardless, the OP's statement that new features and improvements > should go to 4.0.x seems wrong > > > > Yeah, I instinctively thought features and improvements would be moved > to either 4.x or 5.x (not to any subsequent patch version 4.0.x). > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
