RE: Roadmap for 4.0

[Kenneth Brotman]

Someone with an Apache email address has insisted this topic be moved to the 
dev list and not on a Jira so in an effort the help the group concentrate on 
making progress, I’ll post this topic there.  

 

Kenneth Brotman

 

From: Kenneth Brotman [mailto:kenbrot...@yahoo.com] 
Sent: Friday, March 30, 2018 2:44 PM
To: 'user@cassandra.apache.org'
Subject: RE: Roadmap for 4.0

 

Jira 14357:

https://issues.apache.org/jira/browse/CASSANDRA-14357

 

Just list any desired new major features for 4.0 that you want added.  I will 
maintain a compiled list somewhere on this Jira as well.  Don't worry about any 
steps beyond this.  Don't make any judgements about or make any comments at all 
about what others add. 

No judgments at this point.  This is a list of everyone's suggestions.  Add 
your suggestions for new major features you desire be added for version 4.0 
only.

 

Trust me.  This will get the ball rolling.

 

Kenneth Brotman

 

From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Friday, March 30, 2018 2:33 PM
To: user@cassandra.apache.org
Subject: RE: Roadmap for 4.0

 

Does anyone have a simple list of new major features desired for 4.0?  It 
should be a list of things desired regardless of judgements of any kind beyond 
that.  Just start with that  if you want to get anywhere.

 

Kenneth Brotman

 

From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Friday, March 30, 2018 7:30 AM
To: user@cassandra.apache.org
Subject: RE: Roadmap for 4.0

 

Thanks Ben!  

 

I’m reading a book on Cassandra right now that says “The 4.0 release series is 
scheduled to begin in Fall 2016.”  This is one of the group’s first big tests 
since things changed.  

 

Kenneth Brotman

 

From: Ben Bromhead [mailto:b...@instaclustr.com] 
Sent: Friday, March 30, 2018 6:57 AM
To: user@cassandra.apache.org
Subject: Re: Roadmap for 4.0

 

After some further discussions with folks offline, I'd like to revive this 
discussion. 

 

As Kurt mentioned, to keep it simple I if we can simply build consensus around 
what is in for 4.0 and what is out. We can then start the process of working 
off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, 
assigning a timeline to it right now is difficult, but having a firm line in 
the sand around what features/patches are in, then limiting future 4.0 work to 
bug fixes will give folks a less nebulous target to work on. 

 

The other thing to mention is that once we have a 4.0 branch to work off, we at 
Instaclustr have a commitment to dogfooding the release candidates on our 
internal staging and internal production workloads before 4.0 becomes generally 
available. I know other folks have similar commitments and simply having a 4.0 
branch with a clear list of things that are in or out will allow everyone to 
start testing and driving towards a quality release. 

 

The other thing is that there are already a large number of changes ready for 
4.0, I would suggest not recommending tickets for 4.0 that have not yet been 
finished/have outstanding work unless you are the person working on it (or are 
offering to work on it instead) and can get it ready for review in a timely 
fashion. That way we can build a more realistic working target. For major 
breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :)

 

Cheers

 

Ben

 

On Thu, Feb 15, 2018 at 9:39 PM kurt greaves <k...@instaclustr.com> wrote:

I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's 
possible Q3/Q4 alpha/beta is realistic, but definitely not a release. 

Well, this mostly depends on how much stuff to include in 4.0. Either way it's 
not terribly important. If people think 2019 is more realistic we can aim for 
that. As I said, it's just a rough timeframe to keep in mind.

 

3.10 was released in January 2017, and we've got around 180 changes for 4.0 so 
far, and let's be honest, 3.11 is still pretty young so it's going to be a 
significant effort to properly test and verify 4.0. 

Let's just stick to getting a list of changes for the moment. I probably 
shouldn't have mentioned timeframes, let's just keep in mind that we shouldn't 
have such a large set of changes for 4.0 that it takes us years to complete.

 

All that said, what I really care about is building confidence in the release, 
which means an extended testing cycle. If all of those patches landed tomorrow, 
I'd still expect us to be months away from a release, because we need to bake 
the next major - there's too many changes to throw out an alpha/beta/rc and 
hope someone actually runs it. 

Yep. As I said, I'll follow up about testing after we sort out what we're 
actually going to include in 4.0. No point trying to come up with a testing 
plan for 

 

On 13 February 2018 at 04:25, Jeff Jirsa <jji...@gmail.com> wrote:

 

Advantages of cutting a release sooner than later:

1) The project needs to constantly progress forward. Releases are the m

RE: Roadmap for 4.0

[Kenneth Brotman]

Jira 14357:

https://issues.apache.org/jira/browse/CASSANDRA-14357

 

Just list any desired new major features for 4.0 that you want added.  I will 
maintain a compiled list somewhere on this Jira as well.  Don't worry about any 
steps beyond this.  Don't make any judgements about or make any comments at all 
about what others add. 

No judgments at this point.  This is a list of everyone's suggestions.  Add 
your suggestions for new major features you desire be added for version 4.0 
only.

 

Trust me.  This will get the ball rolling.

 

Kenneth Brotman

 

From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Friday, March 30, 2018 2:33 PM
To: user@cassandra.apache.org
Subject: RE: Roadmap for 4.0

 

Does anyone have a simple list of new major features desired for 4.0?  It 
should be a list of things desired regardless of judgements of any kind beyond 
that.  Just start with that  if you want to get anywhere.

 

Kenneth Brotman

 

From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Friday, March 30, 2018 7:30 AM
To: user@cassandra.apache.org
Subject: RE: Roadmap for 4.0

 

Thanks Ben!  

 

I’m reading a book on Cassandra right now that says “The 4.0 release series is 
scheduled to begin in Fall 2016.”  This is one of the group’s first big tests 
since things changed.  

 

Kenneth Brotman

 

From: Ben Bromhead [mailto:b...@instaclustr.com] 
Sent: Friday, March 30, 2018 6:57 AM
To: user@cassandra.apache.org
Subject: Re: Roadmap for 4.0

 

After some further discussions with folks offline, I'd like to revive this 
discussion. 

 

As Kurt mentioned, to keep it simple I if we can simply build consensus around 
what is in for 4.0 and what is out. We can then start the process of working 
off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, 
assigning a timeline to it right now is difficult, but having a firm line in 
the sand around what features/patches are in, then limiting future 4.0 work to 
bug fixes will give folks a less nebulous target to work on. 

 

The other thing to mention is that once we have a 4.0 branch to work off, we at 
Instaclustr have a commitment to dogfooding the release candidates on our 
internal staging and internal production workloads before 4.0 becomes generally 
available. I know other folks have similar commitments and simply having a 4.0 
branch with a clear list of things that are in or out will allow everyone to 
start testing and driving towards a quality release. 

 

The other thing is that there are already a large number of changes ready for 
4.0, I would suggest not recommending tickets for 4.0 that have not yet been 
finished/have outstanding work unless you are the person working on it (or are 
offering to work on it instead) and can get it ready for review in a timely 
fashion. That way we can build a more realistic working target. For major 
breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :)

 

Cheers

 

Ben

 

On Thu, Feb 15, 2018 at 9:39 PM kurt greaves <k...@instaclustr.com> wrote:

I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's 
possible Q3/Q4 alpha/beta is realistic, but definitely not a release. 

Well, this mostly depends on how much stuff to include in 4.0. Either way it's 
not terribly important. If people think 2019 is more realistic we can aim for 
that. As I said, it's just a rough timeframe to keep in mind.

 

3.10 was released in January 2017, and we've got around 180 changes for 4.0 so 
far, and let's be honest, 3.11 is still pretty young so it's going to be a 
significant effort to properly test and verify 4.0. 

Let's just stick to getting a list of changes for the moment. I probably 
shouldn't have mentioned timeframes, let's just keep in mind that we shouldn't 
have such a large set of changes for 4.0 that it takes us years to complete.

 

All that said, what I really care about is building confidence in the release, 
which means an extended testing cycle. If all of those patches landed tomorrow, 
I'd still expect us to be months away from a release, because we need to bake 
the next major - there's too many changes to throw out an alpha/beta/rc and 
hope someone actually runs it. 

Yep. As I said, I'll follow up about testing after we sort out what we're 
actually going to include in 4.0. No point trying to come up with a testing 
plan for 

 

On 13 February 2018 at 04:25, Jeff Jirsa <jji...@gmail.com> wrote:

 

Advantages of cutting a release sooner than later:

1) The project needs to constantly progress forward. Releases are the most 
visible part of that.

2) Having a huge changelog in a release increases the likelihood of bugs that 
take time to find.

 

Advantages of a slower release:

1) We don't do major versions often, and when we do breaking changes (protocol, 
file format, etc), we should squeeze in as many as possible to avoid having to 
roll new majors 

2) There are probably few people actually 

RE: Roadmap for 4.0

[Kenneth Brotman]

Does anyone have a simple list of new major features desired for 4.0?  It 
should be a list of things desired regardless of judgements of any kind beyond 
that.  Just start with that  if you want to get anywhere.

 

Kenneth Brotman

 

From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID] 
Sent: Friday, March 30, 2018 7:30 AM
To: user@cassandra.apache.org
Subject: RE: Roadmap for 4.0

 

Thanks Ben!  

 

I’m reading a book on Cassandra right now that says “The 4.0 release series is 
scheduled to begin in Fall 2016.”  This is one of the group’s first big tests 
since things changed.  

 

Kenneth Brotman

 

From: Ben Bromhead [mailto:b...@instaclustr.com] 
Sent: Friday, March 30, 2018 6:57 AM
To: user@cassandra.apache.org
Subject: Re: Roadmap for 4.0

 

After some further discussions with folks offline, I'd like to revive this 
discussion. 

 

As Kurt mentioned, to keep it simple I if we can simply build consensus around 
what is in for 4.0 and what is out. We can then start the process of working 
off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, 
assigning a timeline to it right now is difficult, but having a firm line in 
the sand around what features/patches are in, then limiting future 4.0 work to 
bug fixes will give folks a less nebulous target to work on. 

 

The other thing to mention is that once we have a 4.0 branch to work off, we at 
Instaclustr have a commitment to dogfooding the release candidates on our 
internal staging and internal production workloads before 4.0 becomes generally 
available. I know other folks have similar commitments and simply having a 4.0 
branch with a clear list of things that are in or out will allow everyone to 
start testing and driving towards a quality release. 

 

The other thing is that there are already a large number of changes ready for 
4.0, I would suggest not recommending tickets for 4.0 that have not yet been 
finished/have outstanding work unless you are the person working on it (or are 
offering to work on it instead) and can get it ready for review in a timely 
fashion. That way we can build a more realistic working target. For major 
breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :)

 

Cheers

 

Ben

 

On Thu, Feb 15, 2018 at 9:39 PM kurt greaves <k...@instaclustr.com> wrote:

I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's 
possible Q3/Q4 alpha/beta is realistic, but definitely not a release. 

Well, this mostly depends on how much stuff to include in 4.0. Either way it's 
not terribly important. If people think 2019 is more realistic we can aim for 
that. As I said, it's just a rough timeframe to keep in mind.

 

3.10 was released in January 2017, and we've got around 180 changes for 4.0 so 
far, and let's be honest, 3.11 is still pretty young so it's going to be a 
significant effort to properly test and verify 4.0. 

Let's just stick to getting a list of changes for the moment. I probably 
shouldn't have mentioned timeframes, let's just keep in mind that we shouldn't 
have such a large set of changes for 4.0 that it takes us years to complete.

 

All that said, what I really care about is building confidence in the release, 
which means an extended testing cycle. If all of those patches landed tomorrow, 
I'd still expect us to be months away from a release, because we need to bake 
the next major - there's too many changes to throw out an alpha/beta/rc and 
hope someone actually runs it. 

Yep. As I said, I'll follow up about testing after we sort out what we're 
actually going to include in 4.0. No point trying to come up with a testing 
plan for 

 

On 13 February 2018 at 04:25, Jeff Jirsa <jji...@gmail.com> wrote:

 

Advantages of cutting a release sooner than later:

1) The project needs to constantly progress forward. Releases are the most 
visible part of that.

2) Having a huge changelog in a release increases the likelihood of bugs that 
take time to find.

 

Advantages of a slower release:

1) We don't do major versions often, and when we do breaking changes (protocol, 
file format, etc), we should squeeze in as many as possible to avoid having to 
roll new majors 

2) There are probably few people actually running 3.11 at scale, so probably 
few people actually testing trunk.

 

In terms of "big" changes I'd like to see land, the ones that come to mind are: 

 

https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes file 
format)

https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient Replicas 
(probably adds new replication strategy or similar)

https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the internode 
netty stuff (no idea if this changes internode stuff, but I bet it's a lot 
easier if it lands on a major)

https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables (selfish 
inclusion, probably doesn't need to be a major at all, and I would

RE: Roadmap for 4.0

[Kenneth Brotman]

Thanks Ben!  

 

I’m reading a book on Cassandra right now that says “The 4.0 release series is 
scheduled to begin in Fall 2016.”  This is one of the group’s first big tests 
since things changed.  

 

Kenneth Brotman

 

From: Ben Bromhead [mailto:b...@instaclustr.com] 
Sent: Friday, March 30, 2018 6:57 AM
To: user@cassandra.apache.org
Subject: Re: Roadmap for 4.0

 

After some further discussions with folks offline, I'd like to revive this 
discussion. 

 

As Kurt mentioned, to keep it simple I if we can simply build consensus around 
what is in for 4.0 and what is out. We can then start the process of working 
off a 4.0 branch towards betas and release candidates. Again as Kurt mentioned, 
assigning a timeline to it right now is difficult, but having a firm line in 
the sand around what features/patches are in, then limiting future 4.0 work to 
bug fixes will give folks a less nebulous target to work on. 

 

The other thing to mention is that once we have a 4.0 branch to work off, we at 
Instaclustr have a commitment to dogfooding the release candidates on our 
internal staging and internal production workloads before 4.0 becomes generally 
available. I know other folks have similar commitments and simply having a 4.0 
branch with a clear list of things that are in or out will allow everyone to 
start testing and driving towards a quality release. 

 

The other thing is that there are already a large number of changes ready for 
4.0, I would suggest not recommending tickets for 4.0 that have not yet been 
finished/have outstanding work unless you are the person working on it (or are 
offering to work on it instead) and can get it ready for review in a timely 
fashion. That way we can build a more realistic working target. For major 
breaking changes, there is always 5.0 or 4.1 or whatever we end up doing :)

 

Cheers

 

Ben

 

On Thu, Feb 15, 2018 at 9:39 PM kurt greaves <k...@instaclustr.com> wrote:

I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's 
possible Q3/Q4 alpha/beta is realistic, but definitely not a release. 

Well, this mostly depends on how much stuff to include in 4.0. Either way it's 
not terribly important. If people think 2019 is more realistic we can aim for 
that. As I said, it's just a rough timeframe to keep in mind.

 

3.10 was released in January 2017, and we've got around 180 changes for 4.0 so 
far, and let's be honest, 3.11 is still pretty young so it's going to be a 
significant effort to properly test and verify 4.0. 

Let's just stick to getting a list of changes for the moment. I probably 
shouldn't have mentioned timeframes, let's just keep in mind that we shouldn't 
have such a large set of changes for 4.0 that it takes us years to complete.

 

All that said, what I really care about is building confidence in the release, 
which means an extended testing cycle. If all of those patches landed tomorrow, 
I'd still expect us to be months away from a release, because we need to bake 
the next major - there's too many changes to throw out an alpha/beta/rc and 
hope someone actually runs it. 

Yep. As I said, I'll follow up about testing after we sort out what we're 
actually going to include in 4.0. No point trying to come up with a testing 
plan for 

 

On 13 February 2018 at 04:25, Jeff Jirsa <jji...@gmail.com> wrote:

 

Advantages of cutting a release sooner than later:

1) The project needs to constantly progress forward. Releases are the most 
visible part of that.

2) Having a huge changelog in a release increases the likelihood of bugs that 
take time to find.

 

Advantages of a slower release:

1) We don't do major versions often, and when we do breaking changes (protocol, 
file format, etc), we should squeeze in as many as possible to avoid having to 
roll new majors 

2) There are probably few people actually running 3.11 at scale, so probably 
few people actually testing trunk.

 

In terms of "big" changes I'd like to see land, the ones that come to mind are: 

 

https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes file 
format)

https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient Replicas 
(probably adds new replication strategy or similar)

https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the internode 
netty stuff (no idea if this changes internode stuff, but I bet it's a lot 
easier if it lands on a major)

https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables (selfish 
inclusion, probably doesn't need to be a major at all, and I wouldn't even lose 
sleep if it slips, but I'd like to see it land)

 

Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a major 
because we'll change something big (like gossip, or the way schema is passed, 
etc):

 

https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly consistent 
membership 

https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly cons

Re: Roadmap for 4.0

[Ben Bromhead]

After some further discussions with folks offline, I'd like to revive this
discussion.

As Kurt mentioned, to keep it simple I if we can simply build consensus
around what is in for 4.0 and what is out. We can then start the process of
working off a 4.0 branch towards betas and release candidates. Again as
Kurt mentioned, assigning a timeline to it right now is difficult, but
having a firm line in the sand around what features/patches are in, then
limiting future 4.0 work to bug fixes will give folks a less nebulous
target to work on.

The other thing to mention is that once we have a 4.0 branch to work off,
we at Instaclustr have a commitment to dogfooding the release candidates on
our internal staging and internal production workloads before 4.0 becomes
generally available. I know other folks have similar commitments and simply
having a 4.0 branch with a clear list of things that are in or out will
allow everyone to start testing and driving towards a quality release.

The other thing is that there are already a large number of changes ready
for 4.0, I would suggest not recommending tickets for 4.0 that have not yet
been finished/have outstanding work unless you are the person working on it
(or are offering to work on it instead) and can get it ready for review in
a timely fashion. That way we can build a more realistic working target.
For major breaking changes, there is always 5.0 or 4.1 or whatever we end
up doing :)

Cheers

Ben

On Thu, Feb 15, 2018 at 9:39 PM kurt greaves  wrote:

> I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's
>> possible Q3/Q4 alpha/beta is realistic, but definitely not a release.
>
> Well, this mostly depends on how much stuff to include in 4.0. Either way
> it's not terribly important. If people think 2019 is more realistic we can
> aim for that. As I said, it's just a rough timeframe to keep in mind.
>
> 3.10 was released in January 2017, and we've got around 180 changes for
> 4.0 so far, and let's be honest, 3.11 is still pretty young so it's going
> to be a significant effort to properly test and verify 4.0.
> Let's just stick to getting a list of changes for the moment. I probably
> shouldn't have mentioned timeframes, let's just keep in mind that we
> shouldn't have such a large set of changes for 4.0 that it takes us years
> to complete.
>
> All that said, what I really care about is building confidence in the
>> release, which means an extended testing cycle. If all of those patches
>> landed tomorrow, I'd still expect us to be months away from a release,
>> because we need to bake the next major - there's too many changes to throw
>> out an alpha/beta/rc and hope someone actually runs it.
>
> Yep. As I said, I'll follow up about testing after we sort out what we're
> actually going to include in 4.0. No point trying to come up with a testing
> plan for
>
> On 13 February 2018 at 04:25, Jeff Jirsa  wrote:
>
>>
>> Advantages of cutting a release sooner than later:
>> 1) The project needs to constantly progress forward. Releases are the
>> most visible part of that.
>> 2) Having a huge changelog in a release increases the likelihood of bugs
>> that take time to find.
>>
>> Advantages of a slower release:
>> 1) We don't do major versions often, and when we do breaking changes
>> (protocol, file format, etc), we should squeeze in as many as possible to
>> avoid having to roll new majors
>> 2) There are probably few people actually running 3.11 at scale, so
>> probably few people actually testing trunk.
>>
>> In terms of "big" changes I'd like to see land, the ones that come to
>> mind are:
>>
>> https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes
>> file format)
>> https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient
>> Replicas (probably adds new replication strategy or similar)
>> https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the
>> internode netty stuff (no idea if this changes internode stuff, but I bet
>> it's a lot easier if it lands on a major)
>> https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables
>> (selfish inclusion, probably doesn't need to be a major at all, and I
>> wouldn't even lose sleep if it slips, but I'd like to see it land)
>>
>> Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a
>> major because we'll change something big (like gossip, or the way schema is
>> passed, etc):
>>
>> https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly
>> consistent membership
>> https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly
>> consistent schema
>>
>> All that said, what I really care about is building confidence in the
>> release, which means an extended testing cycle. If all of those patches
>> landed tomorrow, I'd still expect us to be months away from a release,
>> because we need to bake the next major - there's too many changes to throw
>> out an alpha/beta/rc and hope someone 

Re: Roadmap for 4.0

[kurt greaves]

>
> I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's
> possible Q3/Q4 alpha/beta is realistic, but definitely not a release.

Well, this mostly depends on how much stuff to include in 4.0. Either way
it's not terribly important. If people think 2019 is more realistic we can
aim for that. As I said, it's just a rough timeframe to keep in mind.

3.10 was released in January 2017, and we've got around 180 changes for 4.0
so far, and let's be honest, 3.11 is still pretty young so it's going to be
a significant effort to properly test and verify 4.0.
Let's just stick to getting a list of changes for the moment. I probably
shouldn't have mentioned timeframes, let's just keep in mind that we
shouldn't have such a large set of changes for 4.0 that it takes us years
to complete.

All that said, what I really care about is building confidence in the
> release, which means an extended testing cycle. If all of those patches
> landed tomorrow, I'd still expect us to be months away from a release,
> because we need to bake the next major - there's too many changes to throw
> out an alpha/beta/rc and hope someone actually runs it.

Yep. As I said, I'll follow up about testing after we sort out what we're
actually going to include in 4.0. No point trying to come up with a testing
plan for

On 13 February 2018 at 04:25, Jeff Jirsa  wrote:

>
> Advantages of cutting a release sooner than later:
> 1) The project needs to constantly progress forward. Releases are the most
> visible part of that.
> 2) Having a huge changelog in a release increases the likelihood of bugs
> that take time to find.
>
> Advantages of a slower release:
> 1) We don't do major versions often, and when we do breaking changes
> (protocol, file format, etc), we should squeeze in as many as possible to
> avoid having to roll new majors
> 2) There are probably few people actually running 3.11 at scale, so
> probably few people actually testing trunk.
>
> In terms of "big" changes I'd like to see land, the ones that come to mind
> are:
>
> https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes
> file format)
> https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient
> Replicas (probably adds new replication strategy or similar)
> https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the
> internode netty stuff (no idea if this changes internode stuff, but I bet
> it's a lot easier if it lands on a major)
> https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables
> (selfish inclusion, probably doesn't need to be a major at all, and I
> wouldn't even lose sleep if it slips, but I'd like to see it land)
>
> Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a
> major because we'll change something big (like gossip, or the way schema is
> passed, etc):
>
> https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly
> consistent membership
> https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly
> consistent schema
>
> All that said, what I really care about is building confidence in the
> release, which means an extended testing cycle. If all of those patches
> landed tomorrow, I'd still expect us to be months away from a release,
> because we need to bake the next major - there's too many changes to throw
> out an alpha/beta/rc and hope someone actually runs it.
>
> I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's
> possible Q3/Q4 alpha/beta is realistic, but definitely not a release.
>
>
>
>
> On Sun, Feb 11, 2018 at 8:29 PM, kurt greaves 
> wrote:
>
>> Hi friends,
>> *TL;DR: Making a plan for 4.0, ideally everyone interested should provide
>> up to two lists, one for tickets they can contribute resources to getting
>> finished, and one for features they think would be desirable for 4.0, but
>> not necessarily have the resources to commit to helping with.*
>>
>> So we had that Roadmap for 4.0 discussion last year, but there was never
>> a conclusion or a plan that came from it. Times getting on and the changes
>> list for 4.0 is getting pretty big. I'm thinking it would probably make
>> sense to define some goals to getting 4.0 released/have an actual plan. 4.0
>> is already going to be quite an unwieldy release with a lot of testing
>> required.
>>
>> Note: the following is open to discussion, if people don't like the plan
>> feel free to speak up. But in the end it's a pretty basic plan and I don't
>> think we should over-complicate it, I also don't want to end up in a
>> discussion where we "make a plan to make a plan". Regardless of whatever
>> plan we do end up following it would still be valuable to have a list of
>> tickets for 4.0 which is the overall goal of this email - so let's not get
>> too worked up on the details just yet (save that for after I
>> summarise/follow up).
>>
>> // TODO
>> I think the best way to go about this would be for us to come up with a
>> list of JIRA's 

Re: Roadmap for 4.0

[Jeff Jirsa]

Advantages of cutting a release sooner than later:
1) The project needs to constantly progress forward. Releases are the most
visible part of that.
2) Having a huge changelog in a release increases the likelihood of bugs
that take time to find.

Advantages of a slower release:
1) We don't do major versions often, and when we do breaking changes
(protocol, file format, etc), we should squeeze in as many as possible to
avoid having to roll new majors
2) There are probably few people actually running 3.11 at scale, so
probably few people actually testing trunk.

In terms of "big" changes I'd like to see land, the ones that come to mind
are:

https://issues.apache.org/jira/browse/CASSANDRA-9754 - "Birch" (changes
file format)
https://issues.apache.org/jira/browse/CASSANDRA-13442 - Transient Replicas
(probably adds new replication strategy or similar)
https://issues.apache.org/jira/browse/CASSANDRA-13628 - Rest of the
internode netty stuff (no idea if this changes internode stuff, but I bet
it's a lot easier if it lands on a major)
https://issues.apache.org/jira/browse/CASSANDRA-7622 - Virtual Tables
(selfish inclusion, probably doesn't need to be a major at all, and I
wouldn't even lose sleep if it slips, but I'd like to see it land)

Stuff I'm ok with slipping to 4.X or 5.0, but probably needs to land on a
major because we'll change something big (like gossip, or the way schema is
passed, etc):

https://issues.apache.org/jira/browse/CASSANDRA-9667 - Strongly consistent
membership
https://issues.apache.org/jira/browse/CASSANDRA-10699 - Strongly consistent
schema

All that said, what I really care about is building confidence in the
release, which means an extended testing cycle. If all of those patches
landed tomorrow, I'd still expect us to be months away from a release,
because we need to bake the next major - there's too many changes to throw
out an alpha/beta/rc and hope someone actually runs it.

I don't believe Q3/Q4 is realistic, but I may be biased (or jaded). It's
possible Q3/Q4 alpha/beta is realistic, but definitely not a release.




On Sun, Feb 11, 2018 at 8:29 PM, kurt greaves  wrote:

> Hi friends,
> *TL;DR: Making a plan for 4.0, ideally everyone interested should provide
> up to two lists, one for tickets they can contribute resources to getting
> finished, and one for features they think would be desirable for 4.0, but
> not necessarily have the resources to commit to helping with.*
>
> So we had that Roadmap for 4.0 discussion last year, but there was never a
> conclusion or a plan that came from it. Times getting on and the changes
> list for 4.0 is getting pretty big. I'm thinking it would probably make
> sense to define some goals to getting 4.0 released/have an actual plan. 4.0
> is already going to be quite an unwieldy release with a lot of testing
> required.
>
> Note: the following is open to discussion, if people don't like the plan
> feel free to speak up. But in the end it's a pretty basic plan and I don't
> think we should over-complicate it, I also don't want to end up in a
> discussion where we "make a plan to make a plan". Regardless of whatever
> plan we do end up following it would still be valuable to have a list of
> tickets for 4.0 which is the overall goal of this email - so let's not get
> too worked up on the details just yet (save that for after I
> summarise/follow up).
>
> // TODO
> I think the best way to go about this would be for us to come up with a
> list of JIRA's that we want included in 4.0, tag these as 4.0, and all
> other improvements as 4.x. We can then aim to release 4.0 once all the 4.0
> tagged tickets (+bug fixes/blockers) are complete.
>
> Now, the catch is that we obviously don't want to include too many tickets
> in 4.0, but at the same time we want to make sure 4.0 has an appealing
> feature set for both users/operators/developers. To minimise scope creep I
> think the following strategy will help:
>
> We should maintain two lists:
>
>1. JIRA's that people want in 4.0 and can commit resources to getting
>them implemented in 4.0.
>2. JIRA's that people simply think would be desirable for 4.0, but
>currently don't have anyone assigned to them or planned assignment. It
>would probably make sense to label these with an additional tag in JIRA. 
> *(User's
>please feel free to point out what you want here)*
>
> From list 1 will come our source of truth for when we release 4.0. (after
> aggregating a list I will summarise and we can vote on it).
>
> List 2 would be the "hopeful" list, where stories can be picked up from if
> resourcing allows, or where someone comes along and decides it's good
> enough to work on. I guess we can also base this on a vote system if we
> reach the point of including some of them. (but for the moment it's purely
> to get an idea of what users actually want).
>
> Please don't refrain from listing something that's already been mentioned.
> The purpose is to get an idea of