emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No calc in pretest?


From: Stefan Monnier
Subject: Re: No calc in pretest?
Date: Tue, 02 Jul 2002 16:05:46 -0400

> > > 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]