From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: No calc in pretest? Date: Tue, 02 Jul 2002 16:05:46 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200207022005.g62K5kg19923@rum.cs.yale.edu> References: <200207021952.g62Jqli19065@d-ip-129-15-78-125.cs.ou.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1025640348 14361 127.0.0.1 (2 Jul 2002 20:05:48 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2002 20:05:48 +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 17PTuG-0003jU-00 for ; Tue, 02 Jul 2002 22:05:48 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17PTzQ-0003WH-00 for ; Tue, 02 Jul 2002 22:11:08 +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 17PTuW-0000m0-00; Tue, 02 Jul 2002 16:06:04 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PTuG-0000lS-00 for ; Tue, 02 Jul 2002 16:05:48 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g62K5kg19923; Tue, 2 Jul 2002 16:05:46 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Jon Cast 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:5348 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5348 > > > I don't have any strong feelings, but IMHO changing the major > > > version number after only 3 releases is generally undesirable. > > I don't see any good reason why this should be so. > I don't see any good reason why it shouldn't be so, and I don't see > any bad reason either. Even if you don't think tradition, conformance > to the cultural expectations of Free Software users, etc. are good > reasons, you have to admit they're bad reasons :) What's the fundamental difference betweeen 3 or 4 revisions and 7 (as in the Emacs-20 line) ? Adding cua, tramp, ido, the elisp manual, calc, leim and more isn't enough to justify bumping the major revision counter ? Why not ? > > What about between v17 and v18 ? > I don't think either of those existed. I actually don't know but I'd be surprised if you're right. They might have never been released, but I expected they existed. > > What about between v3 and v4 ? > I know those didn't exist. I again think you're wrong. > > What is the relevance of all of it anyway. > Version number carry information for users, even more than for the > system (although the presence of bug fix releases does change that > slightly. Users aren't expecting bug fix releases, so they aren't > expecting that change, though.) How users will read version numbers > is very important to how they should be set up, just like how users > will read documentation is very important to how it should be set up. Yes, it has some importance. It's important for people to know whether it's just a bugfix release or not. But as for what defines a major change, as I said, this is very subjective. In the past, Emacs revision numbers have been completely useless as "bugfix" indicators and have only been mildly useful as featureset predictors. And I haven't heard many complaints about it, and the only complaints I heard were about distinguishing bugfix-releases, which my 2-part scheme handles just fine. > Are you arguing we don't have a fixed frame of reference to judge > ``major'' from? I think we do (or should): what is a significant step > toward the goals of the Emacs maintainer? Those steps merit major > version number bumps. Others don't. The only definition of "major" that I could find compelling and that seems to corresponds to past practices is "a major rework of the C code". That does not necessarily have anything to do with what users perceive in term of features. So if you consider major release numbers as indicators of "probably buggy because it has a lot of new code", I could agree. But claiming that we should distinguish between the jump from 19.28->19.29 and 19.34->20.1 in terms of features is just not right, because to most people around me, the first jump was more important than the second. > I don't think we have /any/ gain in convenience labeling the current > trunk 22.0 over 21.4. And users expect major releases to be, well, > major. What reason does Emacs have to dis-regard that? Please read my other messages. If 21.4 turns out to be yet-another-bugfix, we'll have to go through the code once again and fix various references to it that assumed that it was going to be a major release. I.e. the point is to choose the revision number long in advance and independent from the number of other releases that will occur in-between. Stefan