From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Updating release version to 22.1 Date: Wed, 09 Feb 2005 09:30:42 +0100 Message-ID: References: <87vf92sqby.fsf@marant.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1107939375 3882 80.91.229.2 (9 Feb 2005 08:56:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 Feb 2005 08:56:15 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, =?utf-8?q?J=C3=A9r=C3=B4me_Marant?= , miles@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 09 09:56:15 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Cyndp-0002lN-Ju for ged-emacs-devel@m.gmane.org; Wed, 09 Feb 2005 09:56:10 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CynsJ-0005uN-Gj for ged-emacs-devel@m.gmane.org; Wed, 09 Feb 2005 04:11:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Cyndg-0003N6-5R for emacs-devel@gnu.org; Wed, 09 Feb 2005 03:56:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Cynda-0003MO-D1 for emacs-devel@gnu.org; Wed, 09 Feb 2005 03:55:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Cynb7-0002rA-7o for emacs-devel@gnu.org; Wed, 09 Feb 2005 03:53:21 -0500 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.34) id 1CynFA-0000Fr-57 for emacs-devel@gnu.org; Wed, 09 Feb 2005 03:30:40 -0500 Original-Received: (qmail 2235 invoked from network); 9 Feb 2005 08:30:38 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 9 Feb 2005 08:30:38 -0000 Original-To: snogglethorpe@gmail.com In-Reply-To: (Miles Bader's message of "Wed, 9 Feb 2005 10:21:22 +0900") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (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: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33118 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33118 Miles Bader writes: > On Wed, 09 Feb 2005 01:17:30 +0100, Kim F. Storm wrote: >> > On Tue, 08 Feb 2005 22:18:41 +0100, J=C3=A9r=C3=B4me Marant wrote: >> >> What's the rational for not using 22.0.x for development versions? >> >> It would be so much simpler ... >>=20 >> Because it - IMO - is confusing. > > What, compared to all the other bizarro schemes being suggested here > ("hey I know, let's make pre-releases _blue_, and real releases > _green_!")? You've got to be kidding... please say you're kidding... Not really! The problem with our _current_ scheme is that even though we seem to want to postpone the decision about exactly what number the next release gets, it is recorded _NUMEROUS_ places all over the sources and other files (in total, I had to change 21.4 to 22.1 in more than 500 places). I don't want us to get into that mess again -- so I want a scheme where the next release number is _fixed_ from the start. This is easily achieved by _always_ using MM.1 (MM =3D 22,23,24...) for releases from the trunk, and MM.N (N =3D 2,3,4...) for bugfixes from the release branch (RC_MM_1). Given that, it seems a little odd that the development version is called something different from MM.1-something... But ok, lets stick with 22.0.50 for now. My primary concern is if some code tests specifically for MM.1 in some way, e.g. "version >=3D MM.1" and the dev/pretest version is MM.0, then we may not see a specific error until we update the version to MM.1 and release the software -- without EVER testing that it works with the actual release number.=20=20 Sadly code _does_ test version numbers! --=20 Kim F. Storm http://www.cua.dk