From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.] Date: Thu, 30 Sep 2004 11:33:18 -0500 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <87brfng1ip.fsf@trouble.defaultvalue.org> References: <1096291271.415813c757a26@imp6-q.free.fr> <20040927134714.GA20012@fencepost> <87hdphx91c.fsf@trouble.defaultvalue.org> <87655wswkv.fsf@trouble.defaultvalue.org> <1096489325.415b196d95987@imp3-q.free.fr> <200409300053.i8U0rWh20758@raven.dms.auburn.edu> <01c4a6f7$Blat.v2.2.2$8c5c2b00@zahav.net.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1096563261 6855 80.91.229.6 (30 Sep 2004 16:54:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 30 Sep 2004 16:54:21 +0000 (UTC) Cc: jerome.marant@free.fr, Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 30 18:54:06 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CD4By-00039Y-00 for ; Thu, 30 Sep 2004 18:54:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CD4IM-0002yb-Hw for ged-emacs-devel@m.gmane.org; Thu, 30 Sep 2004 13:00:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CD41S-00060I-Fz for emacs-devel@gnu.org; Thu, 30 Sep 2004 12:43:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CD3zv-0005c9-Cu for emacs-devel@gnu.org; Thu, 30 Sep 2004 12:41:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CD3ze-0005ZU-2l for emacs-devel@gnu.org; Thu, 30 Sep 2004 12:41:22 -0400 Original-Received: from [66.93.216.237] (helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CD3t9-0004o3-Q1; Thu, 30 Sep 2004 12:34:40 -0400 Original-Received: from trouble.defaultvalue.org (omen.defaultvalue.org [192.168.1.1]) by defaultvalue.org (Postfix) with ESMTP id C37983FB1; Thu, 30 Sep 2004 11:34:38 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id BDB06410A1; Thu, 30 Sep 2004 11:33:19 -0500 (CDT) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Thu, 30 Sep 2004 17:00:05 +0200") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27724 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27724 storm@cua.dk (Kim F. Storm) writes: > Yes, and it is VERY confusion --- since X.Y.Z.NN is really a pretest > of X.(Y+1) I think that's one of the motivations for projects that have gone to the even/odd MINOR convention given the MAJOR.MINOR.MICRO versioning style. Then you can release as many odd-numbered versions as you like, as long as everyone knows the convention. Changing to that approach in guile has been fairly successful, though there are still issues. For example, for the final tests of a X.EVEN.0 candidate (say 1.6.0), you may not want to test something that's actually numbered 1.5.43 in the code, and then change the version to 1.6.0 just before making the release build. Even if that final build has no other changes, it still hasn't been tested. The solution I'm currently using for guile is to actually version the final release candidate as the final release, i.e. 1.6.0, but to name the pre-release tarfiles as guile-1.6.0rcN.tar.gz rather than guile-1.6.0.tar.gz, and then place them on alpha.gnu.org. In all other ways, the release candidate tarfile *is* the tarfile that will become the final release, if no relevant bugs are found. Actually, that's not exactly right. I'm also considering placing a file inside the pre-release indicating that it's a pre-release and indicating which pre-release. When a pre-release (rcN) tarfile finally checks out and is ready to become the the final release, that "pre-release indicator" file will just be removed without building a new dist via tar --delete or similar. This will still leave misleading things like "Guile 1.6.0 released." in a pre-release ChangeLog (when it should really say "Guile 1.6.0 release candidate N.", but in my estimation that's better than alternatives that would require another CVS commit, and building an untested new distfile. Also, since the pre-releases will only be uploaded to alpha.gnu.org, it seems unlikely that someone would end up accidentally confused. -- Rob Browning rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4