Re: Moving tickets out of 4.0 post freeze

[kurt greaves]

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  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 
> CASSANDRA-13254 
> 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  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
> >
> >
>

Re: Moving tickets out of 4.0 post freeze

[Jason Brown]

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 
CASSANDRA-13254 
CASSANDRA-14606 

Thanks,

-Jason

On Tue, Sep 25, 2018 at 4:05 AM, Benedict Elliott Smith  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  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
>
>

Re: Moving tickets out of 4.0 post freeze

[Benedict Elliott Smith]

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  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

Re: Moving tickets out of 4.0 post freeze

[kurt greaves]

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 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
>
>

Re: Moving tickets out of 4.0 post freeze

[Mick Semb Wever]

> 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

Re: Moving tickets out of 4.0 post freeze

[Michael Shuler]

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 flipped the major whenever we felt like “it was the right
> time” and/or for marketing reasons. Might as well drop the charade,
> and C*4 seems as good time as any to do that.

It doesn't have to stay 0. I like your idea of doing meaningful major
release number changes. We could also fix our minor version handling
behavior.

We could use the minor version number to provide meaning for things like
upgrade issues, which in the past have been a random .. version number, buried in NEWS.txt somewhere.
Sometimes people have wished to add new metrics, as an example
improvement, and those have been pushed to the next major. This could be
4.1.0: all the 4.0.x bug fixes, along with "your perf monitoring thing
may break" messaging to users. Still 4.x, but improvements on 4.0 we're
calling 4.1, so beware.

I'm totally spitballing here on possible uses of meaningful minors.

> Perhaps we should discuss this in a separate thread, maybe closer to
> 4.0 release time, so that it doesn’t distract us from more important
> current issues.

Doing this early in the cycle is way better, imo - tests may^Wwill
break, third-party things parsing versions may break. Now would be the
time to make version changes, instead of waiting until the last minute.

Regardless, the OP's statement that new features and improvements should
go to 4.0.x seems wrong - shouldn't that be 5.x? (where version numbers
could/would be 5.0.x, etc.)

Sure, we can create another thread, but since versions break tests and
drivers and such, and were all about making sure tests are clean, it's
relevant, along with deciding what version to move new feature tickets
out to.


Michael

>> On 24 Sep 2018, at 17:55, Jeremiah D Jordan 
>> wrote:
>> 
>> 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 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 users, and I’m not sure what
>>> we got from it?
>>> 
>>> Why don’t we keep it simple, and just have major.patch?  So we
>>> would release simply ‘4’ now, and the next feature release would
>>> be ‘5'.
>>> 
>>> 
>>> 
>>> 
 On 24 Sep 2018, at 17:34, Michael Shuler
  wrote:
 
 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 also means all the tickets for 4.x should be updated to
 4.0.x, 4.0 to 4.0.0, etc.
 
 -- Michael
 
 -

 
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
>> 
> 
> 
> -
>
> 
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

Re: Moving tickets out of 4.0 post freeze

[Aleksey Yeshchenko]

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 right time” and/or for marketing 
reasons. Might as well drop the charade, and C*4 seems as good time as any to 
do that.

Perhaps we should discuss this in a separate thread, maybe closer to 4.0 
release time, so that it doesn’t distract us from more important current issues.

> On 24 Sep 2018, at 17:55, Jeremiah D Jordan  wrote:
> 
> 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  Major>.. 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 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 users, and I’m 
>> not sure what we got from it?
>> 
>> Why don’t we keep it simple, and just have major.patch?  So we would release 
>> simply ‘4’ now, and the next feature release would be ‘5'.
>> 
>> 
>> 
>> 
>>> On 24 Sep 2018, at 17:34, Michael Shuler  wrote:
>>> 
>>> 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 also means
>>> all the tickets for 4.x should be updated to 4.0.x, 4.0 to 4.0.0, etc.
>>> 
>>> -- 
>>> Michael
>>> 
>>> -
>>> 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
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Moving tickets out of 4.0 post freeze

[Benedict Elliott Smith]

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 confusion.

Not that I feel super strongly about it, just that it might be nice to have a 
clean break to sanity, and pretend the past shenanigans never happened.


> On 24 Sep 2018, at 17:55, Jeremiah D Jordan  wrote:
> 
> 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  Major>.. 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 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 users, and I’m 
>> not sure what we got from it?
>> 
>> Why don’t we keep it simple, and just have major.patch?  So we would release 
>> simply ‘4’ now, and the next feature release would be ‘5'.
>> 
>> 
>> 
>> 
>>> On 24 Sep 2018, at 17:34, Michael Shuler  wrote:
>>> 
>>> 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 also means
>>> all the tickets for 4.x should be updated to 4.0.x, 4.0 to 4.0.0, etc.
>>> 
>>> -- 
>>> Michael
>>> 
>>> -
>>> 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
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Moving tickets out of 4.0 post freeze

[Jeremiah D Jordan]

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 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 users, and I’m not 
> sure what we got from it?
> 
> Why don’t we keep it simple, and just have major.patch?  So we would release 
> simply ‘4’ now, and the next feature release would be ‘5'.
> 
> 
> 
> 
>> On 24 Sep 2018, at 17:34, Michael Shuler  wrote:
>> 
>> 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 also means
>> all the tickets for 4.x should be updated to 4.0.x, 4.0 to 4.0.0, etc.
>> 
>> -- 
>> Michael
>> 
>> -
>> 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

Re: Moving tickets out of 4.0 post freeze

[Benedict Elliott Smith]

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 users, and I’m not 
sure what we got from it?

Why don’t we keep it simple, and just have major.patch?  So we would release 
simply ‘4’ now, and the next feature release would be ‘5'.




> On 24 Sep 2018, at 17:34, Michael Shuler  wrote:
> 
> 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 also means
> all the tickets for 4.x should be updated to 4.0.x, 4.0 to 4.0.0, etc.
> 
> -- 
> Michael
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

Re: Moving tickets out of 4.0 post freeze

[Michael Shuler]

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 also means
all the tickets for 4.x should be updated to 4.0.x, 4.0 to 4.0.0, etc.

-- 
Michael

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Moving tickets out of 4.0 post freeze

[Marcus Eriksson]

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 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 that the code is frozen:
>>
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20(fixversion%20%3D%204.0%20OR%20fixversion%20%3D%204.0.0)%20and%20resolution%20%3D%20unresolved%20and%20type%20in%20(%22New%20Feature%22%2C%20Improvement)
>>
>> I propose we move all new features and improvements to 4.0.x to keep the
>> surface area of change for the major stable.
>>
>

Re: Moving tickets out of 4.0 post freeze

[Marcus Eriksson]

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 that the code is frozen:
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20(fixversion%20%3D%204.0%20OR%20fixversion%20%3D%204.0.0)%20and%20resolution%20%3D%20unresolved%20and%20type%20in%20(%22New%20Feature%22%2C%20Improvement)
>
> I propose we move all new features and improvements to 4.0.x to keep the
> surface area of change for the major stable.
>