From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39221 invoked by alias); 10 Sep 2018 16:57:30 -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 39198 invoked by uid 89); 10 Sep 2018 16:57:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 spammy=stability, warrant X-HELO: sessmg22.ericsson.net Received: from sessmg22.ericsson.net (HELO sessmg22.ericsson.net) (193.180.251.58) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Sep 2018 16:57:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1536598645; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+bAekAlvNV2cnDstWnS7Ezw5C8XoxymYiNd4Dh2Xe9M=; b=ep69ThCLNQ4Gnezq8n1AtmHKNBi+9rLYDDnGrxgcmmk82BHsem8PMn13ygDnS4kN OpRH+f+gbXUNkJBGIa1bWEoUBujvmq9Y//b/ynYwqbS0cFUC6oj7CpodrTK00til 4CWdn65H8kxl+cREQOe1iA1X00GTk/Ro3C05JIVSJ1E=; Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.A1.31332.572A69B5; Mon, 10 Sep 2018 18:57:25 +0200 (CEST) Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 10 Sep 2018 18:57:24 +0200 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 10 Sep 2018 18:57:24 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O21eEv1qDG/IeJ8KZ/IWstuyYxj5ltrHGtraMlkUzpA=; b=WvzQ93AwoTJLabYMFOSPpyz9TI3yqQKN7apBI507m8lKKxtEwkmS5RPM9Hm0wwMj8RfydmLq+Cyrk6L3W425NB8AOpkPjBkgwrJVXu2YzOMZ8Qd2gb+rgx7vYg/+PUFrNOZ3xZinvekJhpsRr1YWoU2pa0eTIVlLuevi6imerB0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from [10.129.77.211] (94.119.64.26) by BYAPR15MB2390.namprd15.prod.outlook.com (2603:10b6:a02:8c::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.16; Mon, 10 Sep 2018 16:57:20 +0000 Subject: Re: RFC: Changing GDB's version numbering scheme To: Eli Zaretskii , Joel Brobecker CC: References: <20180910084934.GB3234@adacore.com> <83a7oppmkd.fsf@gnu.org> From: Simon Marchi Message-ID: <4d4af3d3-5dd9-ee5b-965e-48c2b08ed0ee@ericsson.com> Date: Mon, 10 Sep 2018 16:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <83a7oppmkd.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-Path: simon.marchi@ericsson.com Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00277.txt.bz2 On 2018-09-10 01:24 PM, Eli Zaretskii wrote: >> Date: Mon, 10 Sep 2018 09:49:34 +0100 >> From: Joel Brobecker >> >> 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 .. 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