From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: It is time for a feature freeze (it is NOW or never). Date: 05 May 2004 00:21:18 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87eks0654s.fsf@sno.mundell.ukfsn.org> <87n06bp4ng.fsf@sno.mundell.ukfsn.org> <8765cwkejr.fsf@mail.jurta.org> <200404071157.UAA25094@etlken.m17n.org> <200404071312.WAA25268@etlken.m17n.org> <87zn9nqras.fsf@emacswiki.org> <87hdvux5uz.fsf@orebokech.com> <87lll6v514.fsf@orebokech.com> <200404100109.KAA03816@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083709454 17358 80.91.224.253 (4 May 2004 22:24:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 22:24:14 +0000 (UTC) Cc: emacs-devel@gnu.org, monnier@iro.umontreal.ca, "Kim F. Storm" Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 05 00:24:04 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BL8Ka-0004qP-00 for ; Wed, 05 May 2004 00:24:04 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BL8KZ-0003Ns-00 for ; Wed, 05 May 2004 00:24:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BL8Iz-00016Y-Op for emacs-devel@quimby.gnus.org; Tue, 04 May 2004 18:22:25 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BL8Ib-00016A-6I for emacs-devel@gnu.org; Tue, 04 May 2004 18:22:01 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BL8I3-0000wU-Rg for emacs-devel@gnu.org; Tue, 04 May 2004 18:21:59 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BL8I3-0000vo-AZ for emacs-devel@gnu.org; Tue, 04 May 2004 18:21:27 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BL8Hw-0002jj-5y; Tue, 04 May 2004 18:21:20 -0400 Original-To: rms@gnu.org In-Reply-To: Original-Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22763 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22763 Richard Stallman writes: > I think we may as well skip making another release from RC. The > question is whether we should call the next release 21.4 or 22.0. > > There has been so much change that maybe the next release should be > 22.0. While there have been lots of small to medium changes and lots of additions across the board, I don't think that there have been really fundamental changes as compared to 21.0. So the problem is not as much that we have a big change warranting 22.0, but that we have missed out on releasing anything between 21.4 and 21.20. >>From what we have planned right now, immediately after getting the next release out, the Unicode branch will get merged and consolidated, and the multi tty branch merged as well, if feasible. Those are fundamental changes. The Unicode branch is believed to be in pretty good shape, but we want to have a consolidated _released_ version to merge it into. Unicode, in particular with multi tty, will definitely warrant a changed major release number. It would appear awkward to change to 22.0, and right in the next step (after at most 22.1) to 23.0. Merging the bidi branch, in contrast, will probably not warrant a major release step, even though it will mean major work. So in order to avoid version overkill, I think that we would stay at 21.x as long as we have "merely" extensive, but not fundamental changes. > I don't think we are ready for a pretest now. Same here. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum