Andrew Eikum <aeikum@xxxxxxxxxxxxxxx> writes: > My worry is having "2." hang around for another decade or longer. I'd > rather see X.0.0 denote a major feature release (currently represented > as 1.X.0), with X.Y.0 for minor enhancements and X.Y.Z for bugfix. We need three categories: (1) potentially incompatible, (2) feature, (3) fixes-only. We have been doing two levels of features by having both second and third numbers and we are flattening by removing the second one. > It seems reasonable to expect fewer backwards incompatible changes in > the future as Git has become more mature. This reduces the utility of > reserving X.0.0 for major backwards incompatible changes, especially > considering it's already been eight years for the first increment. We are not done yet, far from it. If we can stay at 2.X longer, that is a very good thing. If we followed your numbering scheme, you rob from the users a way to learn about a rare event, a potentially backward-incompatible change. How would you tell your users when the version gap really matters? After hearing "You need to plan carefully when you update to version 47" and then updating to version 47 (or the user may skip that version), the user will learn about a new version 48 and does not hear such a "you need to be careful". What should he think? No news is a good news? He should refrain from updating because the last one was a big one? What if the last time he updated was to version 43, stayed at that version for a long time without paying much attention (as Git grows more and more mature), and now we have version 50 after having a large compatibility gap at version 47 he did not pay much attention because he was skipping? The rarer the important event is, the more necessary that the importance is communicated clearly. -- 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