emacs-devel
[Top][All Lists]
Advanced

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

Re: No calc in pretest?


From: Jon Cast
Subject: Re: No calc in pretest?
Date: Wed, 03 Jul 2002 16:27:38 -0500

address@hidden (Kim F. Storm) wrote:
<snip>
> I don't see any reason to separate CVS snapshot versions from
> pretest versions.  emacsbug.el should (probably) send bug reports
> for either type of build to the emacs-pretest-bug address.

I take it by ``snapshot'' you mean a tarball containing the state of
CVS on a particular date, right?

> So I suggest the following:

> 21.5.0.0          -- Direct build from CVS head.
> 21.5.0.yyyymmdd   -- Snapshot or pretest from CVS head.
> 21.5.1            -- Initial release from CVS head.
> 21.5.x            -- Bug-fix release (x > 1)

Why differentiate CVS from snapshots?  I'd assume the current date
could be written into CVS by a cron script on subversions or
elsewhere, and that would also keep the ordering correct---with your
scheme, my CVS checkout made today (version 21.5.0.0) looks older than
the next guys CVS snapshot release three weeks ago (version
21.5.0.20020803).  That's not good.  It's not catastrophic, but it's
not good.

> The build number is appended to these numbers, so we end up with the
> users seeing numbers like this where y is typically 1.

> 21.5.0.0.y
> 21.5.0.20020703.y
> 21.5.1.y
> 21.5.x.y

> For the release build numbers, this looks ok.

> For the CVS builds, this is also ok, as it clearly differentiates
> these builds from builds based on official releases.

I agree this looks good.  I'm not convinced CVS bugs go to the
emacs-pretest-bug address, but I think the resulting schemes are
sufficiently similar we can go with your scheme unless we get a more
definitive answer.

> > The reason for having separate version numbers for CVS
> > (x.y.0.50.yyyymmdd and x.y.0.9z) is that I think emacsbug.el needs
> > to be able to differentiate them, and that seems easiest to
> > implement

> No, emacsbug counts the number of `.'s in the version string, and if
> there is more than 2 (currently), it supposes it is a pretest.

I know what emacsbug does.  What I meant was, checking a particular
number seems easiest to implement, and (nth 4 (parse-version
emacs-version)) (where `parse-version' returns a list of the
components of its argument) seemed as good a number as any.

> With my scheme, the test would simply be
>         (let ((pretest-p (= emacs-minor-minor-version 0)))
>         ...)

What about bug-fix pretests?  Those probably shouldn't have
emacs-micro-version = 0 --- that destroys the lexical ordering on
versions again.  (Please don't tell me you'd object to calling
21.5.(x+1)'s pretest 21.5.x.90 --- micro numbers have infinitesimal
information for programs anyway.)

> of course, I'm assuming we have a variable containing the
> minor-minor number (can someone come up with a better term?)

Micro number sounds good to me.

> --
> Kim F. Storm <address@hidden> http://www.cua.dk



reply via email to

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