My JIRA experience tells me it would be better to do a blanket update and then go back and fix anything that shouldn't have been updated. Shouldn't be hard that way either because everyones inbox will be flooded with emails, so as long as we all sanity check what got changed we should catch most of the tickets. Alternatively we could go through and tag all the ones that should go to 4.0 beforehand so we can use the tag to filter them out when we do the bulk change. But the former seems easier to crowdsource to me.
On Tue, 25 Sep 2018 at 21:19, Jason Brown <jasedbr...@gmail.com> wrote: > 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 > > > > >
