From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: No calc in pretest? Date: 05 Jul 2002 10:20:09 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200207032135.g63LZOw22583@d-ip-129-15-78-125.cs.ou.edu> <8765zwii4h.fsf@tc-1-100.kawasaki.gol.ne.jp> <200207041824.g64IOBF06432@aztec.santafe.edu> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1025832225 20815 127.0.0.1 (5 Jul 2002 01:23:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 5 Jul 2002 01:23:45 +0000 (UTC) Cc: jcast@ou.edu, storm@cua.dk, pot@gnu.org, eliz@is.elta.co.il, burton@openprivacy.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17QHp3-0005Pc-00 for ; Fri, 05 Jul 2002 03:23:45 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17QHvJ-0008Vf-00 for ; Fri, 05 Jul 2002 03:30:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17QHpP-0001c0-00; Thu, 04 Jul 2002 21:24:07 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17QHmb-0001Xl-00; Thu, 04 Jul 2002 21:21:13 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g651KMR19679; Fri, 5 Jul 2002 10:20:22 +0900 (JST) Original-Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g651KJr22202; Fri, 5 Jul 2002 10:20:21 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g651KI417588; Fri, 5 Jul 2002 10:20:18 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g651KDK19629; Fri, 5 Jul 2002 10:20:13 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id A562A3710; Fri, 5 Jul 2002 10:20:09 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <200207041824.g64IOBF06432@aztec.santafe.edu> Original-Lines: 19 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5499 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5499 Richard Stallman writes: > Perhaps we can use planned gaps in minor version numbers. For > instance, maybe the next non-bug-fix release should be Emacs 21.10. > This is not fundamentally different from inserting an additional > number after the major version, as if the current version were 21.1.2 > and the next non-bug-fix would be 21.2.1. I think leaving a gap is confusing; using minor-minor numbers mirrors what's actually happening quite well, and since it's used by most projects out there, it's very familiar and informative to users. Since the code changes to use minor-minor numbers appear to be (heh) minor, what's the problem with using them? -Miles -- `...the Soviet Union was sliding in to an economic collapse so comprehensive that in the end its factories produced not goods but bads: finished products less valuable than the raw materials they were made from.' [The Economist]