Re: Short-term plans for the post 2.9 cycle

> Jeff King <peff@peff.net> writes:
> 
> > ...  It's
> > not a flag day for either, of course; we'll build in all of the usual
> > backwards-compatibility flags. But it's convenient for users to remember
> > that "3.0" is the minimum to support a new slate of
> > backwards-incompatible features.
> >
> > So my inclination is that the next version is simply v2.10. And maybe
> > you thought of all of this already, and that's why you didn't even
> > bother mentioning it. :) I'm just curious to hear any thoughts on the
> > matter.
> 
> You traced my thought very precisely.  If you take the "It is for
> compatibility breaking release" and "We plan such a release well in
> advance with transition period" together, a natural consequence is
> that by the time we tag one release (e.g. v2.9), it is expected that
> the release notes for it and a few previous releases would all have
> said "in v3.0, this and that things need to be adjusted, but the
> past few releases should have prepared all of you for that change".
> 
> So, no. I do not think the next one can sensibly be v3.0.
> 
> During this cycle what can happen at most is that harbingers of
> compatibility breakers conceived, transition plans for them laid
> out, and the first step for these compatibility breakers included.
> That will still not qualify for a version bump.  The follow-up steps
> for these compatibility breakers may start cooking in 'next', and
> during the next cycle the list may agree they are ready for the
> upcoming release.  At that point, before tagging the last release in
> v2.x series, we already know that the cycle after that will be v3.0
> to include these compatibility breakers.