On Fri, Jun 24, 2016 at 09:54:21AM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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. Thanks, that spells out much better my "we are not ready" thoughts, and I am in complete agreement. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html