From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28754 invoked by alias); 14 Mar 2008 19:45:00 -0000 Received: (qmail 28746 invoked by uid 22791); 14 Mar 2008 19:44:59 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 14 Mar 2008 19:44:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id EF5C42AA4F4; Fri, 14 Mar 2008 15:44:39 -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 CiKxsyQtwhAl; Fri, 14 Mar 2008 15:44:39 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B78952AA4F2; Fri, 14 Mar 2008 15:44:39 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 72BECE7ACB; Fri, 14 Mar 2008 12:44:37 -0700 (PDT) Date: Fri, 14 Mar 2008 19:45:00 -0000 From: Joel Brobecker To: Andreas Schwab , gdb-patches@sourceware.org Subject: Re: [commit/branch] Version set to 6.7.90 Message-ID: <20080314194437.GL3738@adacore.com> References: <20080313175220.GB11778@adacore.com> <20080314172900.GK3738@adacore.com> <20080314175744.GA31306@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080314175744.GA31306@caradoc.them.org> User-Agent: Mutt/1.4.2.2i 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 X-SW-Source: 2008-03/txt/msg00197.txt.bz2 > Right. But if you don't make that snapshot, the first prerelease > should be 6.7.91; version numbers going backwards is bad mojo :-) Roger that - the first pre-release version number will be .90 if it is made immediately after cutting the branch, or .91 if made later. I'm still unsure whether making a pre-release right after cutting the branch brings value or not. On the one hand, it's easier to test, and in many ways more meaningful, a pre-release than something downloaded off a branch. On the other hand, sometimes we know the branch is missing some changes that will come later. Maybe this needs to be a case-by-case judgement call. In the case of the 6.8 release cycle, we could have made a first pre-release immediately. All in all, I'm thinking that we should make it a policy of creating the pre-release immediately. The only case where this would provide no benefit is when we know a major piece is missing, but in this case the branch shouldn't have been cut in the first place, no? -- Joel