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.

The other problem here is uncertainty about the frequency and length of support 
of so called LTS releases. There was a thread about getting off of tick-tock a 
while ago, but it died without coming to any kind of conclusion. Personally, 
I’d like to see us do (non-dev) releases every 6 months, support them for 1 
year, and critical fixes for 2 years.


On November 18, 2016 at 10:25:31 AM, Jason Brown (jasedbr...@gmail.com) wrote:

Hey all,  

Here's an update on the following items:  

NIO meassing/streaming - first is being reviewed; second is getting close  
to review time  
Gossip 2.0 - TL;DR I don't plan on moving cluster metadata (the current  
"gossip" data) onto the new gossip/membership stack until 5.0, so it's not  
a 4.0 blocker. I'll update #12345 with the details I'm thinking about. I  
still want to start getting this code in, though, or at least in discussion.  
Birch - on track  
#11559 (enhanced node representation) - decided it's *not* something we  
need wrt #7544 storage port configurable per node, so we are punting on  
#11559  
#6246 epaxos - if we're targeting Q1 2017 for 4.0, we probably can't get it  
ready by then  
#7544 storage port configurable per node - on track  

So basically, I've removed two items off that list of blockers for 4.0.  
Hope that helps  

-Jason  



On Fri, Nov 18, 2016 at 9:25 AM, sankalp kohli <kohlisank...@gmail.com>  
wrote:  

> Hi Nate,  
> Most of the JIRAs in the middle are being rebased or being  
> reviewed and code is already out there. These will make 4.0 a very solid  
> release.  
>  
> Thanks,  
> Sankalp  
>  
> On Thu, Nov 17, 2016 at 5:10 PM, Ben Bromhead <b...@instaclustr.com> wrote:  
>  
> > We are happy to start testing against completed features. Ideally once  
> > everything is ready for an RC (to catch interaction bugs), but we can do  
> > sooner for features where it make sense and are finished earlier.  
> >  
> > On Thu, 17 Nov 2016 at 16:47 Nate McCall <zznat...@gmail.com> wrote:  
> >  
> > > To sum up that other thread (I very much appreciate everyone's input,  
> > > btw), here is an aggregate list of large, breaking 4.0 proposed  
> > > changes:  
> > >  
> > > CASSANDRA-9425 Immutable node-local schema  
> > > CASSANDRA-10699 Strongly consistent schema alterations  
> > > --  
> > > CASSANDRA-12229 NIO streaming  
> > > CASSANDRA-8457 NIO messaging  
> > > CASSANDRA-12345 Gossip 2.0  
> > > CASSANDRA-9754 Birch trees  
> > > CASSANDRA-11559 enhanced node representation  
> > > CASSANDRA-6246 epaxos  
> > > CASSANDRA-7544 storage port configurable per node  
> > > --  
> > > CASSANDRA-11115 remove thrift support  
> > > CASSANDRA-10857 dropping compact storage  
> > >  
> > > Again, this is the "big things that will probably break stuff" list  
> > > and thus should happen with a major (did I miss anything?). There  
> > > were/are/will be other smaller issues, but we don't really need to  
> > > keep them in front of us for this discussion as they can/will just  
> > > kind of happen w/o necessarily affecting anything else.  
> > >  
> > > That all said, since we are 'doing a software' we need to start  
> > > thinking about the above in balance with resources and time. However,  
> > > a lot of the above items do have a substantial amount of code written  
> > > against them so it's not as daunting as it seems.  
> > >  
> > > What I would like us to discuss is rough timelines and what is needed  
> > > to get these out the door.  
> > >  
> > > One thing that sticks out to me: that big chunk in the middle there is  
> > > coming out of the same shop in Cupertino. I'm nervous about that. Not  
> > > that that ya'll are not capable, I'm solely looking at it from the  
> > > "that is a big list of some pretty hard shit" perspective.  
> > >  
> > > So what else do we need to discuss to get these completed? How and  
> > > where can other folks pitch in?  
> > >  
> > > -Nate  
> > >  
> > --  
> > Ben Bromhead  
> > CTO | Instaclustr <https://www.instaclustr.com/>  
> > +1 650 284 9692  
> > Managed Cassandra / Spark on AWS, Azure and Softlayer  
> >  
>  

Reply via email to