As far as I know, it was Steve who changed the numbering. I've never
liked it, and I suggest we switch back to the old system. I actually
talk about this a fair amount in Architecting XEmacs; here's an excerpt:
First of all, it needs to be immediately clear from the version number
whether the release is a beta
release or a net release. Steve has proposed getting rid of the beta
version numbering system, which I
think would be a big mistake. Furthermore, the net release version
number and beta release version
number should be kept separate, just as they are now, to make it
completely clear where any
particular release stands. There may be alternate ways of phrasing a
beta release other than
something like 21.0 beta 34, but in all such systems, the beta number
needs to be zero for any release
version. Three possible alternative systems, none of which I like very
much, are:
1.The beta number is simply an extra number in the regular version
number. Then, for example,
21.0 beta 34 becomes 21.0.34. The problem is that the release
version, which would simply
be called 21.0, appears to be earlier than 21.0 beta 34.
2.The beta releases appear as later revisions of earlier releases.
Then, for example, 21.1 beta 34
becomes 21.0.34, and 21.0 beta 34 would have to become 21.-1.34.
This has both the
obvious ugliness of negative version numbers and the problem that
it makes beta releases
appear to be associated with their previous releases, when in fact
they are more closely
associated with the following release.
3.Simply make the beta version number be negative. In this scheme,
you'd start with something
like -1000 as the first beta, and then 21.0 beta 34 would get
renumbered to 21.0.-968.
Obviously, this is a crazy and convoluted scheme as well, and we
would be best to avoid it.
Currently, the between-beta snapshots are not numbered, but I think that
they probably should be. If
appropriate scripts are handled to automate beta release, it should be
very easy to have a version
number automatically updated whenever a snapshot is made. The number
could be added either as a
separate snapshot number, and you'd have 21.0 beta 34 pre 1, which
becomes before 21.0 beta 34;
or we could make the beta number be floating point, and then the same
snapshot would have to be
called 21.0 beta 33.1. The latter solution seems quite kludgey to me.
Martin Buchholz wrote:
Somewhere along the line we renamed the 21.2 tarballs from
xemacs-21.2-b3.tar.gz
to
xemacs-21.2.16.tar.gz
Is the current naming convention documented?
Is it a bug that xemacs is still *installed* into directories with
names like xemacs-21.2-b23 ??
ObPatch (completely untested):
--- configure.in 1999/12/08 07:43:35 1.111.2.53
+++ configure.in 1999/12/09 12:17:43
@@ -954,12 +954,11 @@
AC_DEFINE_UNQUOTED(EMACS_MAJOR_VERSION, $emacs_major_version)
AC_DEFINE_UNQUOTED(EMACS_MINOR_VERSION, $emacs_minor_version)
if test -n "$emacs_beta_version" ; then
+ version="${version}.${emacs_beta_version}"
if test "$beta" = "yes"; then
- version="${version}-b${emacs_beta_version}"
- AC_DEFINE_UNQUOTED(EMACS_BETA_VERSION, $emacs_beta_version)
+ AC_DEFINE_UNQUOTED(EMACS_BETA_VERSION, $emacs_beta_version)
else
- version="${version}.${emacs_beta_version}"
- AC_DEFINE_UNQUOTED(EMACS_PATCH_LEVEL, $emacs_beta_version)
+ AC_DEFINE_UNQUOTED(EMACS_PATCH_LEVEL, $emacs_beta_version)
fi
fi
AC_DEFINE_UNQUOTED(XEMACS_CODENAME, "$xemacs_codename")
--
In order to save my hands, I am cutting back on my responses, especially
to XEmacs-related mail. You _will_ get a response, but please be
patient.
If you need an immediate response and it is not apparent in your
message,
please say so. Thanks for your understanding.