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. -- 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