cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Jirsa <jeff.ji...@crowdstrike.com>
Subject Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)
Date Fri, 18 Nov 2016 23:22:13 GMT
We should assume that we’re ditching tick/tock. I’ll post a thread on 4.0-and-beyond here
in a few minutes.

The advantage of a prod release every 6 months is fewer incentive to push unfinished work
into a release.
The disadvantage of a prod release every 6 months is then we either have a very short lifespan
per-release, or we have to maintain lots of active releases. 

2.1 has been out for over 2 years, and a lot of people (including us) are running it in prod
– if we have a release every 6 months, that means we’d be supporting 4+ releases at a
time, just to keep parity with what we have now? Maybe that’s ok, if we’re very selective
about ‘support’ for 2+ year old branches. 


On 11/18/16, 3:10 PM, "beggleston@apple.com on behalf of Blake Eggleston" <beggleston@apple.com>
wrote:

>> While stability is important if we push back large "core" changes until later we're
just setting ourselves up to face the same issues later on
>
>In theory, yes. In practice, when incomplete features are earmarked for a certain release,
those features are often rushed out, and not always fully baked.
>
>In any case, I don’t think it makes sense to spend too much time planning what goes
into 4.0, and what goes into the next major release with so many release strategy related
decisions still up in the air. Are we going to ditch tick-tock? If so, what will it’s replacement
look like? Specifically, when will the next “production” release happen? Without knowing
that, it's hard to say if something should go in 4.0, or 4.5, or 5.0, or whatever.
>
>The reason I suggested a production release every 6 months is because (in my mind) it’s
frequent enough that people won’t be tempted to rush features to hit a given release, but
not so frequent that it’s not practical to support. It wouldn’t be the end of the world
if some of these tickets didn’t make it into 4.0, because 4.5 would fine.
>
>On November 18, 2016 at 1:57:21 PM, kurt Greaves (kurt@instaclustr.com) wrote:
>
>On 18 November 2016 at 18:25, Jason Brown <jasedbrown@gmail.com> wrote:  
>
>> #11559 (enhanced node representation) - decided it's *not* something we  
>> need wrt #7544 storage port configurable per node, so we are punting on  
>>  
>
>#12344 - Forward writes to replacement node with same address during replace  
>depends on #11559. To be honest I'd say #12344 is pretty important,  
>otherwise it makes it difficult to replace nodes without potentially  
>requiring client code/configuration changes. It would be nice to get #12344  
>in for 4.0. It's marked as an improvement but I'd consider it a bug and  
>thus think it could be included in a later minor release.  
>
>Introducing all of these in a single release seems pretty risky. I think it  
>> would be safer to spread these out over a few 4.x releases (as they’re  
>> finished) and give them time to stabilize before including them in an LTS  
>> release. The downside would be having to maintain backwards compatibility  
>> across the 4.x versions, but that seems preferable to delaying the release  
>> of 4.0 to include these, and having another big bang release.  
>
>
>I don't think anyone expects 4.0.0 to be stable. It's a major version  
>change with lots of new features; in the production world people don't  
>normally move to a new major version until it has been out for quite some  
>time and several minor releases have passed. Really, most people are only  
>migrating to 3.0.x now. While stability is important if we push back large  
>"core" changes until later we're just setting ourselves up to face the same  
>issues later on. There should be enough uptake on the early releases of 4.0  
>from new users to help test and get it to a production-ready state.  
>
>
>Kurt Greaves  
>kurt@instaclustr.com  


Mime
View raw message