Re: RFC: Changing GDB's version numbering scheme

[Simon Marchi <simon.marchi@ericsson.com>]

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