From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.devel Subject: Re: No calc in pretest? Date: Tue, 02 Jul 2002 18:09:16 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200207021528.g62FSST17855@rum.cs.yale.edu> <87d6u6uno9.fsf@tc-1-100.kawasaki.gol.ne.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1025626337 11991 127.0.0.1 (2 Jul 2002 16:12:17 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2002 16:12:17 +0000 (UTC) Cc: "Stefan Monnier" , Eli Zaretskii , storm@cua.dk, Emacs Devel Mailing List Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17PQGG-00037I-00 for ; Tue, 02 Jul 2002 18:12:16 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17PQLM-0006cc-00 for ; Tue, 02 Jul 2002 18:17:32 +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 17PQG4-0004rs-00; Tue, 02 Jul 2002 12:12:04 -0400 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PQDa-0004fo-00; Tue, 02 Jul 2002 12:09:30 -0400 Original-Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.5/8.12.5) with ESMTP id g62G9D6w022896; Tue, 2 Jul 2002 18:09:14 +0200 Original-To: Miles Bader Mail-Copies-To: nobody X-Hashcash: 020702:miles@gnu.org:88b80c0419fd74da X-Hashcash: 020702:monnier@rum.cs.yale.edu:85ee7e0837b2ce16 X-Hashcash: 020702:eliz@is.elta.co.il:bbbdce0e75eea5de X-Hashcash: 020702:storm@cua.dk:205fe5f04b9bc86c X-Hashcash: 020702:emacs-devel@gnu.org:69799d450a9d3d11 In-Reply-To: <87d6u6uno9.fsf@tc-1-100.kawasaki.gol.ne.jp> (Miles Bader's message of "03 Jul 2002 00:58:30 +0900") Original-Lines: 37 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) 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:5329 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5329 Miles Bader writes: > "Stefan Monnier" writes: >> If it's more convenient to name the current trunk 22.0, then I think it >> should be done. > > No one has presented a good reason why it would be more convenient either. One reason is that we don't have to update :version fields and documentation if there is a well defined versioning scheme. > Kim said: >> I switched to 22.x since introducing a new numbering scheme in the >> middle of an existing non-conforming numbering scheme (as 21.x) >> doesn't make sense... > > but I can't see any reason why that's true, since it isn't really a `new > numbering scheme'; it's more of a minor tweak. The only thing people > really depend on about future emacs version numbers is that they > increase, and that they `make sense', and I don't think it's any more > confusing to start using minor-minor release numbers with 21.4.x than it > would be with 22.1.x -- whereas I guarantee that people _will_ wonder > `Whoa, emacs 22 already! What great feature did they add?!', and go > away disappointed if they hear it's `just a version number adjustment.' But there are major changes in CVS HEAD, that is the whole point of calling it Emacs 22, which I think is a good idea. Releasing CVS HEAD as 21.4 would be a mistake, as users would think "Pah, emacs 21.4, I already have 21.2 and it works, I won't bother upgrading.". What is major and what isn't major is not something objectively true. Many users probably don't care if Emacs uses MULE or Unicode internally even though it is major work, and also many users regards window transparency as something major altough it is little work. Having faster development cycles has always been one of my gripes with emacs, new features shouldn't have to wait 3-4 years.