RFC: Changing GDB's version numbering scheme

RFC: Changing GDB's version numbering scheme

[Joel Brobecker]

Hello,

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

Re: RFC: Changing GDB's version numbering scheme

[Eli Zaretskii]

> Date: Mon, 10 Sep 2018 09:49:34 +0100
> From: Joel Brobecker <brobecker@adacore.com>
> 
> The proposal, to avoid this issue, is to change the version numbering
> scheme to increment the major version for each release branch.

With the current release schedule, you will have the major version
increase very rapidly, for no good reason, because, for example, the
difference between GDB 8.1 and 8.2, feature-wise, is very small, so is
not really appropriate (IMO) for a new major version.

Do we care about this downside?

Re: RFC: Changing GDB's version numbering scheme

[Simon Marchi]

On 2018-09-10 01:24 PM, Eli Zaretskii wrote:
>> Date: Mon, 10 Sep 2018 09:49:34 +0100
>> From: Joel Brobecker <brobecker@adacore.com>
>>
>> The proposal, to avoid this issue, is to change the version numbering
>> scheme to increment the major version for each release branch.
> 
> With the current release schedule, you will have the major version
> increase very rapidly, for no good reason, because, for example, the
> difference between GDB 8.1 and 8.2, feature-wise, is very small, so is
> not really appropriate (IMO) for a new major version.
> 
> Do we care about this downside?

The problem is that there's no easy definition of what constitutes a
big-enough feature to warrant a major number bump.  There's no more
difference between 7.12/8.0 than between 8.0/8.1.  Our major number
doesn't really guarantee anything, such as API or command stability.
So the major bumps are pretty much arbitrary (what would you think
constitutes a good reason for a major bump?).  If we allowed ourselves
to break backwards compatibility (command syntax, MI output, Python API),
then it would make sense to have <MAJOR>.<MINOR>.<PATCH> and bump the
major number when this happens.

One of the arguments expressed at the Cauldron was: if we're going to
use an arbitrary numbering scheme, we might as well follow GCC's
scheme.  The other one, as Joel mentioned, is that the current scheme
leads people to think (we've had an example recently) that a major
bump represents some breakage, and that they better avoid upgrading
to a release that has a new major version.

As for the quickly increasing number, some major projects are doing
this (Chromium 69, Firefox 62), and it seems to work well for them.

Simon

Re: RFC: Changing GDB's version numbering scheme

[André Pönitz]

On Mon, Sep 10, 2018 at 09:49:34AM +0100, Joel Brobecker wrote:
> Hello,

Hallo Joel.

Taking the liberty, even if probably not in the intended target audience:

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

And if you change it, other people (or, possibly the same), will get
confused by the other scheme.

As long as there's no deeper meaning behind that (like guarantees
on certain behaviour, source/binary compatibility, which are not *that*
important in the GDB context) changing the versioning scheme merely
annoys people, not because of the exact scheme, but because of change.

> 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) [...]
>   (b) [...]
>   (b) (sic) [...]
>   (c) [...]
>   (d) [...]
>   (e) [...]
>   (f) [...]
>   (g) [...]
>   (h) [...]

I am trying to imagine a situation where 36 lines of explanation of a
numbering scheme helps people that *guess* wrong on any other numbering
scheme

And I fail.

Andre'

Re: RFC: Changing GDB's version numbering scheme

[Joel Brobecker]

> I am trying to imagine a situation where 36 lines of explanation of a
> numbering scheme helps people that *guess* wrong on any other numbering
> scheme
> 
> And I fail.

I get what you are saying, but focusing on the length of the explanation
doesn't work in my opinion, because the "explanation" is actually
a detailed procedure for ourselves of what we will have to do in terms
of the new numbering scheme, which is an implementation detail.

What the GDB user will be seeing, on the other hand, is 2 or 3 releases
per major version, and those releases with the same major version are
made from the same branch, and therefore are fairly close in terms of
the code base.

-- 
Joel

Re: RFC: Changing GDB's version numbering scheme

[Joel Brobecker]

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

Re: RFC: Changing GDB's version numbering scheme

[Alan Hayward]

> 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

Re: RFC: Changing GDB's version numbering scheme

[Andrew Burgess]

* Joel Brobecker <brobecker@adacore.com> [2018-10-31 10:25:13 -0700]:

> 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 would support changing the numbering scheme.

The problem I see with the current scheme is that I don't understand
what the criteria is for bumping the major version number.  Maybe it's
one of those things that you'll just know it when you see it.

For me the concern that the new scheme could cause confusion is not a
big one, under both the old and new scheme version 10.1 is "better"
than 9.1, and 9.2 is "better" than 9.1.  The only difference is that
under the new scheme 9.2 is more closely related to 9.1 than it used
to be.  Most users I suspect only care about finding the "best"
release currently available.

In the rare case that someone feels that they really can't move onto a
new GDB branch for *reasons*, then they might not move from 9.1 to 9.2
because that used to mean a new branch.  This is easy enough to solve
by just rewording the website to make it clear that 9.2 is the next
release for the v9 branch.

Thanks,
Andrew


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

Re: RFC: Changing GDB's version numbering scheme

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

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

I'm also in favor of it.  Historically I don't think the minor versions
carried much meaning.  In the new scheme, I suppose the version still
won't carry much meaning, but at least it won't pretend, and will be
easy to explain.  Also, it is closer to what GCC does, which I think is
a plus.

Tom

Re: RFC: Changing GDB's version numbering scheme

[John Baldwin]

On 11/6/18 2:27 PM, Tom Tromey wrote:
>>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
> 
> Joel> Quick summary of the discussion so far: The only feedback this
> Joel> discussion drew was negative feedback. If you would like to support
> Joel> this proposal, you should speak up; otherwise, I'm inclined to
> Joel> let the matter drop.
> 
> I'm also in favor of it.  Historically I don't think the minor versions
> carried much meaning.  In the new scheme, I suppose the version still
> won't carry much meaning, but at least it won't pretend, and will be
> easy to explain.  Also, it is closer to what GCC does, which I think is
> a plus.

I also probably favor the new scheme for similar reasons to what Simon
articulated which is that there doesn't appear (to me) to be a clear
meaning of major version bumps (e.g. what qualifies gdb 6 vs 7 vs 8).
It seems gdb 7 -> 8 was maybe about switching from C to C++?  I haven't
been around the project long enough to be aware of other major bumps and
what they might have (or have not) signified, but it actually felt that
7.12 -> 8.0 was really about the same relative change as 7.11 -> 7.12 or
8.0 -> 8.1.  In the FreeBSD package we currently treat the major.minor
together as the "real" version number installing the binary as
/usr/local/bin/gdb{711,712,8,81,82} FWIW.

-- 
John Baldwin