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: 04 May 2004 09:14:26 +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 1083655346 15773 80.91.224.253 (4 May 2004 07:22:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 07:22:26 +0000 (UTC) Cc: emacs-devel@gnu.org, Stefan Monnier , rms@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 04 09:22:18 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 1BKuFu-0000w5-00 for ; Tue, 04 May 2004 09:22:18 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKuFt-0001HD-00 for ; Tue, 04 May 2004 09:22:18 +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 1BKuEu-00062H-4s for emacs-devel@quimby.gnus.org; Tue, 04 May 2004 03:21:16 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKu98-00046B-CA for emacs-devel@gnu.org; Tue, 04 May 2004 03:15:18 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKu8S-0003lj-IA for emacs-devel@gnu.org; Tue, 04 May 2004 03:15:07 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKu8R-0003lV-QE for emacs-devel@gnu.org; Tue, 04 May 2004 03:14:35 -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 1BKu8K-0002oZ-HQ; Tue, 04 May 2004 03:14:29 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 60 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:22684 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22684 storm@cua.dk (Kim F. Storm) writes: > Stefan Monnier writes: > > > >> In that case, I guess we should aim for a release without the > > >> unicode branch. And certainly without the multi-tty branch. > > >> (As for the tiling and lexical branches, I am not convinced I > > >> want to make those changes.) > > > > > So when do we declare "feature freeze" ? May 1st ? > > > > May 1st sounds very good to me, > > > Did we decide on naming the next release 21.5 ? > > It's simpler just to stick with 21.4 and do some real work, but if we > must change it, who will make an effort to change 21.4 -> 21.5 > throughout the sources. I think that 21.4 has been mentioned frequently as probably another bug fix release, and 21.5 is "half-way" to 22.0. Since we will need quite some time of consolidation before we can hope to get out the new feature release, reserving 21.4 for a possible bug fix release in case something horrible turns up that needs immediate fixing during that time might not do harm. And if we don't need to release a 21.4 in the mean time, the version number jump will then perhaps be somewhat of an indicator that there was a larger change. It's annoying if you write things like "will be available in version 21.4 and later" in some manual and then have to admit that you were lying. And 21.4 has already been earmarked as a non-trunk release in some announcements or comments. So if we skip this bugfix release, let us also skip the number. > To speed up things even further, should we make a pretest now? > > We could announce to the pretesters that it is an early pre-test, > but believed to be stable and ask the pretesters to actively start > using it so we can get feedback asap. Believed to be stable? With several unresolved lockups and display problems and last-minute additions? I think that would be unfair. "Workable" and "worth it" would be more like it. > I suggest that we set the USE_LSB_TAG for GNU/Linux and Mac/OS for > the first pretest; we can then enable it for more ports in the next > pretest. I suggest that before doing a formal pretest release, we let the last changes shake down a few weeks among developers. Well, at least till Mother's Day. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum