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: No calc in pretest? Date: 02 Jul 2002 23:10:56 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <5xsn31esyn.fsf@kfs2.cua.dk> References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1025640716 15251 127.0.0.1 (2 Jul 2002 20:11:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2002 20:11:56 +0000 (UTC) Cc: Simon Josefsson , 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 17PU0B-0003xf-00 for ; Tue, 02 Jul 2002 22:11:55 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17PU5M-0003iE-00 for ; Tue, 02 Jul 2002 22:17:16 +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 17PU0N-0001OZ-00; Tue, 02 Jul 2002 16:12:07 -0400 Original-Received: from mail.filanet.dk ([195.215.206.179]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17PTye-0001Cv-00 for ; Tue, 02 Jul 2002 16:10:20 -0400 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id 306FC7C017; Tue, 2 Jul 2002 20:10:18 +0000 (GMT) Original-To: Eli Zaretskii In-Reply-To: Original-Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:5351 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5351 Eli Zaretskii writes: > On Tue, 2 Jul 2002, Simon Josefsson wrote: > > > One reason is that we don't have to update :version fields and > > documentation if there is a well defined versioning scheme. > > I sincerely doubt that the version-update problem will go away with > _any_ versioning scheme. > > If we want to solve this annoyance, we should find a solution for it that > doesn't require manual work when versions change numbers. The aim should be to use a numbering scheme which does not require us to change the numbers once we have decided on the number for the next "major" release. And we should be able to make that decision immediately after making a release. And it must allow us to make interrim bug-fix releases. Stefan's proposal to simply increment the major number for every non-bugfix release, and the minor number for bug-fix releases is both simple and straight-forward to implement. > > Having faster development cycles has always been one of my gripes with > > emacs, new features shouldn't have to wait 3-4 years. > > I'd say that's an exaggeration: not even 1 year has passed since v21.1, > so new features in CVS head now could be available within the next 6 > months, say. That's slightly more than 1 year since 21.1, the last > non-bugfix release. Incrementing the major number every 18 months doesn't seem unreasonable to me. I'd assume that "enough" changes have been made in those 18 months to warrant a new "major" release. Maybe not a quantum leap, but at least significantly different from the previous major release. -- Kim F. Storm http://www.cua.dk