This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Changing GDB's version numbering scheme


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'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]