Re: No calc in pretest?

[Jon Cast]

Stefan Monnier <monnier+gnu/address@hidden> wrote:
> > > > 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.

OK, let me expand on my comment: the major version number before 19
was (IIRC) 1: the version before v19 was 1.18.

> > > What about between v3 and v4 ?

> > I know those didn't exist.

> I again think you're wrong.

There was no GNU Emacs 3 or GNU Emacs 4.  There were 1.3 and 1.4, but
that was a minor change.

<snip>

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

If we start making major releases on an annual basis, expect to start
hearing complaints :)

<snip>

> The only definition of "major" that I could find compelling

No comment on this

> and that seems to corresponds to past practices

So because past practice has been less than stellar at identifying
what should be a major release, we should drop the distinction?

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

What /was/ this crucial change from 19.28->19.29?  I'm curious now
(and given that there /was/ a 19.28, I'm wondering if there shouldn't
have been more major releases in there).

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

That's a one-time cost.  As I've pointed out, at some point my scheme
would take over and (nearly) /eliminate/ version number changes.  The
only change that would be possible is if we change a version from a
minor flip to a major flip, but that change would almost certainly
involve changing feature sets, too.  And then, :version tags will have
to roll anyway :)

>       Stefan

Jon Cast