Re: where to find list of mailing lists (was Re: emacs21 cursor...)

[Eli Zaretskii]

[CC'ed to emacs-devel, since I don't think it's a DOS-only problem.]

For those who didn't follow the thread on comp.emacs: the issue is
that the code in emacsbug.el which decides whether to mail the bug
report to bug-gnu-emacs or to emacs-pretest-bug uses the Emacs version
string.  If the version contains 3 or more dots, as in 21.0.91.3, it
decides that this is a pretest; otherwise it treats it as a released
version.

On 28 Nov 2000, Jason Rumney wrote:

> Eli Zaretskii <address@hidden> writes:
> 
> > The problem is that the code in loadup.el which appends a .N minor number to
> > emacs-version (and bumps it each new build) doesn't get run on all systems.
> > E.g., my Emacs tells it's 21.0.91, not 21.0.91.1.
> 
> I see the exception there for MSDOS. Could you modify the code so that
> only the code which involves invalid file names is not run, but
> appending ".1" to the filename still happens? This is effectively what
> happens on NT, since those files are not created by the build process.

FWIW, I wonder whether it is at all a good idea to base the decision
about pretest vs released version on that snippet.  (I wasn't even
aware the version was being used for that purposes, until Stefan
posted his reply which led to this discussion.)

Here are some cases where that logic might fail, in addition to the
MS-DOS case that you mentioned.

  - systems which cannot dump Emacs (I suspect that on those systems,
    the code in loadup.el won't DTRT);

  - a user could at her discretion modify emacs-version definition on
    version.el, for any number of reasons.

So I wonder whether we don't overload the minor version number with
too much payload.  Wouldn't it be better to define a separate defconst
which would explicitly mark this version as a pretest, for example?

Also please note that I'm not suggesting any changes before 21.1.
The code we are discussing was there since 1996, so it can be left
alone for a few more months ;-)