@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>
> On Fri, Sep 16, 2016 at 5:05 AM, Sylvain Lebresne <sylv...@datastax.com>
> > 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
> > 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
> > of
> > only bug fixes during the testing phase, one can hope critical fixes
> > be
> > fairly rare, less than 1 per Y period on average). Further, it's
> > to
> > be stable and fixes are supposed to be critical, so doing hot-fix
> > 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