Re: What's cooking in git.git (Feb 2014, #04; Wed, 12)

[Junio C Hamano <gitster@pobox.com>]

Andrew Eikum <aeikum@codeweavers.com> 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.