cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksey Yeschenko <alek...@apache.org>
Subject Re: cassandra-3.1 branch and new merge order
Date Tue, 10 Nov 2015 12:47:07 GMT
3.0.1 and 3.1 will be identical this time around - that’s just a consequence of the transition.
Starting with 3.0.2 and 3.2, however, the branches will diverge.

Skipping one or the other would look weird and break continuity, so we are still going to
release both, despite them containing the same code.

-- 
AY

On 10 November 2015 at 12:14:19, Björn Hegerfors (bj0rn@spotify.com) wrote:

So there is no reason for an end-user to actually use 3.1, because it will  
have the same features as 3.0.x, but won't be maintained? 3.0.x for high x  
will be 3.1 plus more bug fixes. I'm not saying that's bad. Starting from  
3.2, using any subsequent version will make sense.  

On Tue, Nov 10, 2015 at 12:43 PM, Paulo Motta <pauloricardomg@gmail.com>  
wrote:  

> 3.0.x is an interim branch during the transition to the new tick tock  
> release model, which will receive backported patches from bug-fix releases  
> (3.1, 3.3, etc) that affect 3.0, so no new features will go into 3.0.x. So  
> users can safely go to 3.0 before adopting tick tock, knowing they will be  
> served with bug fixes in the 3.0.x series following the old model.  
>  
> 2015-11-09 22:12 GMT-08:00 Phil Yang <ud1937@gmail.com>:  
>  
> > 2015-11-10 0:35 GMT+08:00 Aleksey Yeschenko <aleksey@apache.org>:  
> > >  
> > > - cassandra-3.0 branch is going to continue representing the 3.0.x  
> series  
> > > of releases (3.0 bugfixes only, as no new feature are supposed to go  
> into  
> > > 3.0.x release series)  
> > > - cassandra-3.1 branch will contain 3.0 bugfixes *only*  
> > >  
> >  
> > What is the difference between 3.0.x series and 3.1?  
> >  
> >  
> >  
> > > - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1  
> and  
> > > new features)  
> > >  
> > > --  
> > > AY  
> >  
> >  
> >  
> >  
> > --  
> > Thanks,  
> > Phil Yang  
> >  
>  

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message