Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "André Pönitz" <apoenitz@t-online.de>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: RFC: Changing GDB's version numbering scheme
Date: Mon, 10 Sep 2018 17:08:00 -0000	[thread overview]
Message-ID: <20180910171243.GB1832@klara.mpi.htwm.de> (raw)
In-Reply-To: <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'


  parent reply	other threads:[~2018-09-10 17:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10  8:49 Joel Brobecker
2018-09-10 12:24 ` Eli Zaretskii
2018-09-10 16:57   ` Simon Marchi
2018-09-10 17:08 ` André Pönitz [this message]
2018-09-10 17:32   ` Joel Brobecker
2018-10-31 17:25 ` Joel Brobecker
2018-11-01  9:31   ` Alan Hayward
2018-11-06 22:27   ` Tom Tromey
2018-11-07 16:46     ` John Baldwin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180910171243.GB1832@klara.mpi.htwm.de \
    --to=apoenitz@t-online.de \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox