From: Rob Browning <rlb@defaultvalue.org>
Cc: emacs-devel@gnu.org
Subject: Re: DONE: Updating release version to 22.1
Date: Wed, 09 Feb 2005 11:39:12 -0600 [thread overview]
Message-ID: <87is51bpkv.fsf@trouble.defaultvalue.org> (raw)
In-Reply-To: <m3is51vhqs.fsf@kfs-l.imdomain.dk> (Kim F. Storm's message of "Wed, 09 Feb 2005 17:08:11 +0100")
storm@cua.dk (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
next prev parent reply other threads:[~2005-02-09 17:39 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-08 13:06 Updating release version to 22.1 Kim F. Storm
2005-02-08 13:34 ` David Kastrup
2005-02-08 14:46 ` Stefan Monnier
2005-02-08 15:05 ` Kim F. Storm
2005-02-08 15:43 ` Han Boetes
2005-02-08 16:24 ` David Kastrup
2005-02-08 15:58 ` David Kastrup
2005-02-08 20:12 ` Kim F. Storm
2005-02-08 21:18 ` Jérôme Marant
2005-02-08 22:34 ` David Kastrup
2005-02-08 22:38 ` Miles Bader
2005-02-09 0:17 ` Kim F. Storm
2005-02-09 0:32 ` David Kastrup
2005-02-09 1:21 ` Miles Bader
2005-02-09 8:30 ` Kim F. Storm
2005-02-09 8:41 ` Miles Bader
2005-02-09 11:23 ` Kim F. Storm
2005-02-09 13:32 ` Robert J. Chassell
2005-02-09 13:59 ` David Kastrup
2005-02-09 14:15 ` Jason Rumney
2005-02-10 18:39 ` Richard Stallman
2005-02-10 21:49 ` Kim F. Storm
2005-02-10 22:33 ` Jérôme Marant
2005-02-10 22:52 ` David Kastrup
2005-02-09 14:21 ` Lennart Borgman
2005-02-09 14:56 ` Kim F. Storm
2005-02-09 9:44 ` Lute Kamstra
2005-02-09 10:54 ` Kim F. Storm
2005-02-09 10:45 ` David Kastrup
2005-02-09 10:52 ` Miles Bader
2005-02-09 11:33 ` Kim F. Storm
2005-02-10 6:01 ` Richard Stallman
2005-02-09 16:08 ` DONE: " Kim F. Storm
2005-02-09 16:32 ` David Kastrup
2005-02-09 17:39 ` Rob Browning [this message]
2005-02-10 6:01 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87is51bpkv.fsf@trouble.defaultvalue.org \
--to=rlb@defaultvalue.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.