Re: RFC: Changing GDB's version numbering scheme

[Joel Brobecker <brobecker at adacore dot com>]

Hello again,

Quick summary of the discussion so far: The only feedback this
discussion drew was negative feedback. If you would like to support
this proposal, you should speak up; otherwise, I'm inclined to
let the matter drop.

> During this year's GNU Cauldron, we discussed the version numbering
> scheme the GDB project has been following so far, because a number
> of users were confused by it.
> 
> At the moment, as you know, GDB's version number is composed of at
> least 2 numbers (MAJOR.MINOR) with an optional micro version suffix
> (MAJOR.MINOR.MICRO). During each release cycle, we usually increase
> the minor number. For instance, since the last release branch was
> an 8.2 branch, the next GDB release branch is currently expected to
> be 8.3.
> 
> The problem with that numbering is that a number of users got confused
> by that numbering, thinking that all releases made with the same MAJOR
> number were made from the same release branch. So, they thought for
> instance that 8.0, 8.1 and 8.2 were made from the same branch.
> 
> The proposal, to avoid this issue, is to change the version numbering
> scheme to increment the major version for each release branch. We did
> not go into too much detail during the discussion, but generally
> speaking, so part of the proposal below is me extrapolating in terms
> of some of the details while thinking things through a little more --
> please feel free to comment and provide other suggestions.
> 
> Let's assume that the last release we made had a major version number
> of <N> (in our case, <N> is 8):
> 
>   (a) The next branch would be gdb-<N+1>-branch
> 
>   (b) Once the branch is cut, we increment the version number on
>       master to be <N+1>.50.DATE
> 
>   (b) The first pre-release would be numbered "GDB <N+1>.0.90" [2].
>       For instance, our next pre-release would be "GDB 9.0.90".
> 
>       If more pre-releases are needed, we would then increase
>       the MICRO number, so "GDB 9.0.91", GDB "9.0.92", etc.
>       Note that additional pre-release are fairly rarely needed
>       (but have occasionally happened, so we need to be prepared
>       to generate them).
> 
>       I'll explain the use of micro numbers after the procedure
>       is laid out (to avoid clogging the general procedure with
>       details) [1].
> 
>   (c) Once the pre-release is out, the version number gets updated
>       to include the date again, so "<N+1>.0.90.DATE".
> 
>   (d) The first official release off a release branch would have
>       the MINOR number set to "1". Thus: "GDB <N+1>.1".
> 
>       Following that principle, our next major GDB release will be
>       GDB 9.1.
> 
>   (e) Once the GDB 9.1 release is made, we switch the branch's version
>       to "<N+1>.1.90.DATE".
> 
>   (f) The next official release would be "<N+1>.2".
> 
>   (g) Once "<N+1>.2" is out, the version number would be set to
>       "<N+1>.2.90.DATE" again.
> 
>   (h) Same principle if additional releases are needed ("<N+1>.3", etc).
> 
> [1] One property I wanted to have in the procedure above was to have
>     a consistent minor number for the first official release, so as to
>     know that GDB <X>.1 is always the first official release from branch
>     <X>.  Combined with the potential need for multiple pre-releases,
>     and the fact that we want to have increasing version numbers, and
>     dated version numbers in between, the only way I found was to use
>     the <X>.0.9X range.
> 
>     One alternative to using <N+1>.0.90 for pre-release would be to use
>     <N>.90. It's a shorter version number, and I would be OK with that,
>     but my sense is that it's kind of confusing that a pre-release
>     would have a different major version.
> 
> [2] Minor note: In the majority of the release cycles, we create the first
>     pre-release right after the branch is cut. However, there have been
>     cycles in the past were we wanted to wait for specific fixes before
>     creating the first pre-release. In those situations, the first
>     pre-release will be "<N+1>.0.91" instead. I don't think it really
>     is all that important.
> 
> Thoughts? If we agree, I will update gdb/version.in, and look at the
> documentation update.
> 
> -- 
> Joel

-- 
Joel