From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81569 invoked by alias); 31 Oct 2018 17:25:22 -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 81546 invoked by uid 89); 31 Oct 2018 17:25:20 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=090, 0.90, drew, H*f:sk:2018091 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 31 Oct 2018 17:25:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4019A56067 for ; Wed, 31 Oct 2018 13:25:16 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NW0BO2U-A46m for ; Wed, 31 Oct 2018 13:25:16 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 0C76A56013 for ; Wed, 31 Oct 2018 13:25:16 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 03AAB83AF5; Wed, 31 Oct 2018 10:25:13 -0700 (PDT) Date: Wed, 31 Oct 2018 17:25:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: RFC: Changing GDB's version numbering scheme Message-ID: <20181031172513.GB4081@adacore.com> 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> User-Agent: Mutt/1.9.4 (2018-02-28) X-SW-Source: 2018-10/txt/msg00758.txt.bz2 Hello again, Quick summary of the discussion so far: The only feedback this discussion drew was negative feedback. If you would like to support this proposal, you should speak up; otherwise, I'm inclined to let the matter drop. > 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. > > 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) The next branch would be gdb--branch > > (b) Once the branch is cut, we increment the version number on > master to be .50.DATE > > (b) The first pre-release would be numbered "GDB .0.90" [2]. > For instance, our next pre-release would be "GDB 9.0.90". > > If more pre-releases are needed, we would then increase > the MICRO number, so "GDB 9.0.91", GDB "9.0.92", etc. > Note that additional pre-release are fairly rarely needed > (but have occasionally happened, so we need to be prepared > to generate them). > > I'll explain the use of micro numbers after the procedure > is laid out (to avoid clogging the general procedure with > details) [1]. > > (c) Once the pre-release is out, the version number gets updated > to include the date again, so ".0.90.DATE". > > (d) The first official release off a release branch would have > the MINOR number set to "1". Thus: "GDB .1". > > Following that principle, our next major GDB release will be > GDB 9.1. > > (e) Once the GDB 9.1 release is made, we switch the branch's version > to ".1.90.DATE". > > (f) The next official release would be ".2". > > (g) Once ".2" is out, the version number would be set to > ".2.90.DATE" again. > > (h) Same principle if additional releases are needed (".3", etc). > > [1] One property I wanted to have in the procedure above was to have > a consistent minor number for the first official release, so as to > know that GDB .1 is always the first official release from branch > . Combined with the potential need for multiple pre-releases, > and the fact that we want to have increasing version numbers, and > dated version numbers in between, the only way I found was to use > the .0.9X range. > > One alternative to using .0.90 for pre-release would be to use > .90. It's a shorter version number, and I would be OK with that, > but my sense is that it's kind of confusing that a pre-release > would have a different major version. > > [2] Minor note: In the majority of the release cycles, we create the first > pre-release right after the branch is cut. However, there have been > cycles in the past were we wanted to wait for specific fixes before > creating the first pre-release. In those situations, the first > pre-release will be ".0.91" instead. I don't think it really > is all that important. > > Thoughts? If we agree, I will update gdb/version.in, and look at the > documentation update. > > -- > Joel -- Joel