From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9136 invoked by alias); 10 Sep 2018 12:24:46 -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 9004 invoked by uid 89); 10 Sep 2018 12:24:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=rapidly X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Sep 2018 12:24:32 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fzLEx-0004kX-S9 for gdb-patches@sourceware.org; Mon, 10 Sep 2018 08:24:30 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fzLEx-0004kN-KD; Mon, 10 Sep 2018 08:24:27 -0400 Received: from [176.228.60.248] (port=1212 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fzLEx-0007TC-5g; Mon, 10 Sep 2018 08:24:27 -0400 Date: Mon, 10 Sep 2018 12:24:00 -0000 Message-Id: <83a7oppmkd.fsf@gnu.org> From: Eli Zaretskii To: Joel Brobecker CC: gdb-patches@sourceware.org In-reply-to: <20180910084934.GB3234@adacore.com> (message from Joel Brobecker on Mon, 10 Sep 2018 09:49:34 +0100) Subject: Re: RFC: Changing GDB's version numbering scheme References: <20180910084934.GB3234@adacore.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00257.txt.bz2 > 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?