I'm not a huge fan of leaving features to rot unmerged for a couple months. What is wrong with "new features go to trunk, stable branches get forked at release?"
On Mon, Nov 9, 2015 at 10:54 AM, Jake Luciani <jak...@gmail.com> wrote: > Looking back at the tick-tock email chain we never really discussed this. > > Rather than having 3.1 and trunk I think we should have just trunk. > > I'd rather not let features sit in a branch with bugfixes going on top that > can decay. > They should be merged in when it's time to merge features for 3.even, post > 3.odd. > > I know we have features in trunk today that aren't in 3.0 and we probably > shouldn't have done that. > > > > > > > On Mon, Nov 9, 2015 at 11:35 AM, Aleksey Yeschenko <alek...@apache.org> > wrote: > > > With 3.0.0 vote to be over soon, tick-tock is officially starting, and we > > are creating a new branch for cassandra-3.1 release. > > > > New merge order: cassandra-2.2 -> cassandra-3.0 -> cassandra-3.1 -> trunk > > > > - 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* > > - trunk represents the upcoming cassandra-3.2 release (fixes from 3.1 and > > new features) > > > > -- > > AY > > > > > -- > http://twitter.com/tjake > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
