Re: RFC: Changing GDB's version numbering scheme

[Alan Hayward <Alan dot Hayward at arm dot com>]

> On 31 Oct 2018, at 17:25, Joel Brobecker <brobecker@adacore.com> wrote:
> 
> 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.


I’m for this change and am in agreement with Simon’s comments.

As a product matures, the reasons for advancing the major number shrink.
Often it ends up being a “marketing” decision to advance - elsewhere I’ve
seen large internal code refactors get bundled as a minor release and
small interface changes cause a major release.
If I remember it right, Linux was stuck on 2.6.X until it was decided to
just choose the next release to go to 3.0.0, as there was nothing big
enough to declare a major change. Meanwhile Binutils is stuck on 2.31.1
and Glibc 2.29 (although I think there are reasons for glibc to not
move). I’d hope gdb would never get stuck and end up with 8.29.1.

I’ve seen products move to a year numbered scheme (eg 19.1 for 2019) to
avoid this. That’s an alternative choice for gdb, but I don’t think the
right one here.

There are roughly two main GDB releases each year, so by moving to the
new scheme that’s only two bumps every year. It’s not going to escalate
rapidly like Firefox and Chrome. In 2028, it’ll be GDB 28.1, which sounds
reasonable to me.

If GDB is going to move, then I think it should be it asap, before GCC
gets far enough ahead that GDB isn't (roughly) in sync.


Alan.

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