This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Changing GDB's version numbering scheme
- From: André Pönitz <apoenitz at t-online dot de>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 10 Sep 2018 19:12:43 +0200
- Subject: Re: RFC: Changing GDB's version numbering scheme
- References: <20180910084934.GB3234@adacore.com>
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'