@Sylvain - I see what you're saying now on the branches. I suppose a branching strategy like that does give some flexibility to have multiple things in the pipeline so it does give some additional flexibility there.
On Mon, Sep 19, 2016 at 9:06 AM Eric Evans <john.eric.ev...@gmail.com> wrote: > On Fri, Sep 16, 2016 at 5:05 AM, Sylvain Lebresne <sylv...@datastax.com> > wrote: > > In light of all this, my suggesting for a release cycle woud be: > > - To have 3 branches: 'features', 'testing' and 'stable', with an X month > > rotation: 'features' becomes 'testing' after X months and then 'stable' > > after > > X more, before getting EOL X months later. > > - The feature branch gets everything. The testing branch only gets bug > > fixes. > > The stable branch only gets critical bug fixes. And imo, we should be > very > > strict on this (I acknowledge that there is sometimes a bit of > > subjectivity on > > whether something is a bug or an improvement, and if it's critical or > > not, but > > I think it's not that hard to get consensus if we're all reasonable > > (though it > > might worth agreeing on some rough but written guideline upfront)). > > - We release on a short and fixed cadence of Y month(s) for both the > > feature and > > testing branch. For the stable branch, given that it already had X > months > > of > > only bug fixes during the testing phase, one can hope critical fixes > will > > be > > fairly rare, less than 1 per Y period on average). Further, it's > supposed > > to > > be stable and fixes are supposed to be critical, so doing hot-fix > releases > > probably makes the most sense (though it probably only work if we're > > indeed > > strict on what is considered critical). > > This seems pretty close to what Mck suggested; I think this could work. > > > -- > Eric Evans > john.eric.ev...@gmail.com >
