From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54859 invoked by alias); 10 Sep 2018 17:08:51 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 54849 invoked by uid 89); 10 Sep 2018 17:08:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=Let's, Lets, imagine, H*r:encrypted X-HELO: mailout04.t-online.de Received: from mailout04.t-online.de (HELO mailout04.t-online.de) (194.25.134.18) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Sep 2018 17:08:48 +0000 Received: from fwd03.aul.t-online.de (fwd03.aul.t-online.de [172.20.27.148]) by mailout04.t-online.de (Postfix) with SMTP id EF3114191B43; Mon, 10 Sep 2018 19:08:45 +0200 (CEST) Received: from localhost (Vas1HwZEwhPYWw+YGwGTzQz8251E31FEzbdsIj38cViV+KcMd+CImgSAHJT2luUgPP@[91.65.230.147]) by fwd03.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1fzPg4-3JUl1c0; Mon, 10 Sep 2018 19:08:44 +0200 Date: Mon, 10 Sep 2018 17:08:00 -0000 From: =?iso-8859-1?Q?Andr=E9_P=F6nitz?= To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: RFC: Changing GDB's version numbering scheme Message-ID: <20180910171243.GB1832@klara.mpi.htwm.de> References: <20180910084934.GB3234@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180910084934.GB3234@adacore.com> X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00278.txt.bz2 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 (in our case, 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'