Re: DONE: Updating release version to 22.1

[Rob Browning]

address@hidden (Kim F. Storm) writes:

> I have installed these changes:
>
>       Change release version from 21.4 to 22.1 throughout.
>
>       Change development version from 21.3.50 to 22.0.50.

As long as the convention that X.0.Y is a development pre-release is
well-publicized, this seems like a reasonable convention.

With respect to some of the other comments in this thread:

  - It would be perfectly fine as far as Debian' is concerned for you
    to use dashes in your version names, i.e. 22.0-pre22.1-3.
    (http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version)
    Debian only presumes that its "revision" is what comes after the
    final dash (if any).

    (Using something like a 22.0 prefix would also mean that this
     version will still sort reasonably when 22.1 is finally released.
     Although Debian can always work around upstream numbering
     inconsistencies.  That's what version epochs are for.)

  - Given the 22.0.50 approach above, what's the plan for *stable*
    pre-release versions?  Say that 22.1 is the current release, and
    you need to make some tricky change for 22.3, tricky enough that
    you want to make an official pre-release for testing.  (Perhaps
    that's not a viable scenario.)

  - I wonder if it might be helpful to separate out the "pre-release"
    status and make it official, i.e. have emacs-major-version,
    emacs-minor-version, *and* emacs-prerelease.  The latter might be
    an integer for pre-releases and nil otherwise.  This would allow
    you to programatically decide when to expose/hide the pre-release
    status.  i.e. in display strings, you might want to show it, but
    most code would only want to look at major/minor.

  - It seems like the name used for a particular release might best
    depend on the context.  Given the variable separation above, you
    might name the file emacs-22.1-pre4.tar.gz, have emacs-version
    report "GNU Emacs 22.1 (prerelease 4) ...", and have emacs-major,
    minor, and prerelease set to 22, 1, and 4 respectively.  Then as
    mentioned, most important code would be acting on the values
    planned for the official release.  Only code that needed to check
    for emacs-prerelease would, and the only real difference between
    the final (tested) pre-release and the official release would be
    (setq emacs-prerelease nil).

  - The now-defunct idea of naming the next major release 21.4 might
    have caused some problems for Debian and perhaps other
    distributions.  This is because Debian allows people to install
    and run older "major" versions of emacs.

    Right now we have emacs20 and emacs21 (though emacs20 is about to
    be dropped), and the current system expects that installing a new
    version of emacsX won't break or change much.

    If 21.4 had been a major departue from 21.3, then we would have
    had to re-work our packaging so that instead of an emacs21
    package, we'd have emacs21.4.  We would also have had to change
    some internals.  For example, the value of debian-emacs-flavor
    would have to be emacs21.4 rather than emacs21, and any add-on
    package's code that presumed that flavors wouldn't have a "." in
    them would be in trouble.

    This is probably not a huge concern for you, but I thought I'd
    mention it.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4