RFC patchhowto/maintain-git.txt: new version numbering scheme

> We wanted to call the upcoming release "Git 1.9", with its
> maintenance track being "Git 1.9.1", "Git 1.9.2", etc., but various
> third-party tools are reported to assume that there are at least
> three dewey-decimal components in our version number.
>
> Adjust the plan so that vX.Y.0 are feature releases while vX.Y.Z
> (Z > 0) are maintenance releases.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * Haven't committed to this outline, but I am raising a
>   weather-balloon to see reaction from the list.  Comments?

>
> Documentation/howto/maintain-git.txt | 18 +++++++++++-------
> 1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/howto/maintain-git.txt
> b/Documentation/howto/maintain-git.txt
> index 33ae69c..ca43787 100644
> --- a/Documentation/howto/maintain-git.txt
> +++ b/Documentation/howto/maintain-git.txt
> @@ -39,26 +39,26 @@ The policy on Integration is informally mentioned
> in "A Note
> from the maintainer" message, which is periodically posted to
> this mailing list after each feature release is made.
>
> - - Feature releases are numbered as vX.Y.Z and are meant to
> + - Feature releases are numbered as vX.Y.0 and are meant to
>    contain bugfixes and enhancements in any area, including
>    functionality, performance and usability, without regression.
>
>  - One release cycle for a feature release is expected to last for
>    eight to ten weeks.
>
> - - Maintenance releases are numbered as vX.Y.Z.W and are meant
> -   to contain only bugfixes for the corresponding vX.Y.Z feature
> -   release and earlier maintenance releases vX.Y.Z.V (V < W).
> + - Maintenance releases are numbered as vX.Y.Z and are meant
> +   to contain only bugfixes for the corresponding vX.Y.0 feature
> +   release and earlier maintenance releases vX.Y.W (W < Z).
>
>  - 'master' branch is used to prepare for the next feature
>    release. In other words, at some point, the tip of 'master'
> -   branch is tagged with vX.Y.Z.
> +   branch is tagged with vX.Y.0.
>
>  - 'maint' branch is used to prepare for the next maintenance
> -   release.  After the feature release vX.Y.Z is made, the tip
> +   release.  After the feature release vX.Y.0 is made, the tip
>    of 'maint' branch is set to that release, and bugfixes will
>    accumulate on the branch, and at some point, the tip of the
> -   branch is tagged with vX.Y.Z.1, vX.Y.Z.2, and so on.
> +   branch is tagged with vX.Y.1, vX.Y.2, and so on.
>
>  - 'next' branch is used to publish changes (both enhancements
>    and fixes) that (1) have worthwhile goal, (2) are in a fairly
> @@ -86,6 +86,10 @@ this mailing list after each feature release is
> made.
>    users are encouraged to test it so that regressions and bugs
>    are found before new topics are merged to 'master'.
>
> +Note that before v1.9.0 release, the version numbers used to be
> +structured slightly differently.  vX.Y.Z were feature releases while
> +vX.Y.Z.W were maintenance releases for vX.Y.Z.
> +
>
> A Typical Git Day
> -----------------
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

> If we are progressing from V1.9 to V2.0 quickly (one cycle?), which I
> understand is the plan, then mixing the minor development items (patch
> series which progress to master) with the maintenance fixes over the
> next few months, thus only having 1.9.x releases, sounds reasonable.
>
> If there is going to be separate maintenance fixes from the patch series
> developments then keeping to the previous 1.9.x.y for maintenance would
> be better.
>
> Will the new rapid counting continue after V2.0, such that we get to
> V2.9 -> V3.0 rather more quickly than V1.0 -> V2.0 ?
>
> The key discriminator would be to say when V2.0 will be out for deciding
> the V1.9 sequence.

> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> If we are progressing from V1.9 to V2.0 quickly (one cycle?), which I
>> understand is the plan, then mixing the minor development items 
>> (patch
>> series which progress to master) with the maintenance fixes over the
>> next few months, thus only having 1.9.x releases, sounds reasonable.
>>
>> If there is going to be separate maintenance fixes from the patch 
>> series
>> developments then keeping to the previous 1.9.x.y for maintenance 
>> would
>> be better.
>>
>> Will the new rapid counting continue after V2.0, such that we get to
>> V2.9 -> V3.0 rather more quickly than V1.0 -> V2.0 ?
>>
>> The key discriminator would be to say when V2.0 will be out for 
>> deciding
>> the V1.9 sequence.
>
> I do not quite follow.  The time distance between v1.9 and v2.0
> should not affect anything.  If it is a long road, there may be
> v1.10, v1.11, v1.12, ...

>            before we have v2.0.  If not, v2.0 may
> immediately follow v1.9 as a new feature release.  There may be
> maintenance releases based on v1.9 that does not add any new
> features.
>
> Right now, if you count the maintenance releases, there are
> potentially four kinds of version gaps:
>
> - Between v1.8.5 and v1.8.5.1, there are fixes but no new features;
>
> - Between v1.8.5 and v1.8.6, there are new features but no
>   compatibility worries;
>
> - Between v1.8.6 and v1.9.0, there are new features, no
>   compatibility worries, but somehow the jump is larger than the
>   one between v1.8.5 and v1.8.6; and
>
> - Between v1.9.0 and v2.0.0, there are new features and also
>   compatibility concerns.
>
> Switching to 2-digit scheme and calling the upcoming one v1.9 (and
> the next major one v2.0) was meant to make the naming more flat,

>    as
> the third item in the above list "somehow the jump is larger" does
> not seem to add much value to the end users.  So the logical
> numbering becomes more like this:
>
> - Between v1.9 and v1.9.1, there are fixes but no new features;
>
> - Between v1.9.x and v1.10, there are new features but no
>   compatibility worries;
>
> - Between v1.9.x and v2.0, there are new features and also
>   compatibility concerns.
>
> With a twist, though.  There seem to be many places where at least
> three digits are assumed to exist in our version numbers, so in
> order to make life easier, the updated document says vX.Y (a feature
> release) will identify itself as vX.Y.0