Re: Moving tickets out of 4.0 post freeze

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

Re: Moving tickets out of 4.0 post freeze

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

Re: Moving tickets out of 4.0 post freeze

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

Re: Moving tickets out of 4.0 post freeze

Yeah so lets not derail any further and just put them all to 4.x (as I'm sure OP originally intended) and we can figure out versioning later. On Tue, 25 Sep 2018 at 12:07, Mick Semb Wever wrote: > > > > > I'm totally spitballing here on possible uses of meaningful minors. > > Continuing the

Re: Moving tickets out of 4.0 post freeze

> 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

Re: Moving tickets out of 4.0 post freeze

On 9/24/18 12:21 PM, Aleksey Yeshchenko wrote: > We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with > minor forever fixed to 0. > > But I’m also struggling with how to justify the existence of that > unused digit. We have never really done semantic versioning, we’ve > arbitrarily

Re: Moving tickets out of 4.0 post freeze

We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with minor forever fixed to 0. But I’m also struggling with how to justify the existence of that unused digit. We have never really done semantic versioning, we’ve arbitrarily flipped the major whenever we felt like “it was the

Re: Moving tickets out of 4.0 post freeze

I think we’ve confused people plenty so far, that I’m not sure there’s much confusion to be saved by not making a clean break. For 3.x (where x > 0 and x < 11) were, after all, .[.] For some reason, at 11, we sort of switched back to semver? But seemingly only to enjoy everyone’s further

Re: Moving tickets out of 4.0 post freeze

So as to not confuse people, even if we never put out a 4.1, I think we should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x. And yes our .. versioning of the past never followed semver. -Jeremiah > On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith > wrote: > > I’d like to propose we

Re: Moving tickets out of 4.0 post freeze

I’d like to propose we don’t do Semver. Back when we did this before, there wasn’t any clear distinction between a major and a minor release. They were both infrequent, both big, and were treated as majors for EOL'ing support for older releases. This must surely have been confusing for

Re: Moving tickets out of 4.0 post freeze

On 9/24/18 7:09 AM, Joshua McKenzie wrote: > I propose we move all new features and improvements to 4.0.x to keep the > surface area of change for the major stable. It occurs to me that we should probably update the version in trunk to 4.0.0, if we're following semantic versions. I suppose this

Re: Moving tickets out of 4.0 post freeze

ok, I guess I should read properly, we should only fix bugs On Mon, Sep 24, 2018 at 3:42 PM Marcus Eriksson wrote: > I have used the 4.0 version as a "we need this before releasing 4.0" - do > you have another way of marking tickets we need fixed before releasing? > > On Mon, Sep 24, 2018 at

Re: Moving tickets out of 4.0 post freeze

I have used the 4.0 version as a "we need this before releasing 4.0" - do you have another way of marking tickets we need fixed before releasing? On Mon, Sep 24, 2018 at 2:09 PM Joshua McKenzie wrote: > We have quite a few tickets still flagged for 4.0 that aren't in keeping > with the idea