• Download
• XEmacs in GSoC
• FAQ
• Mailing lists
• Documentation
• People
• How to help
• Bugs
• Links

• Mailing lists
• Status of Services
• Near Future
• History of XEmacs
• XEmacs vs. GNU Emacs
• Screenshots
• Sites Created With XEmacs
• Year 2000 Statement
• Who Wrote XEmacs?
• XEmacs Contributors
• Website

• Download
• Optional Libraries
• Installation HOWTOs
• Quickstart Package Guide
• Documentation
• Installation resources
• Releases

• XEmacs Packages
• Other Interesting Sites
• Customization Links

• FAQ
• Reporting Bugs
• Troubleshooting resources
• Debugging

• How to help
• XEmacs in GSoC
• Open Issues
• Who Wrote XEmacs?
• XEmacs Contributors
• Dev team responsibilities
• Architecting XEmacs

Release Numbering Policy

Revised: 10 January 2001

The current development branch has version numbers of the form 21.2.x. The CVS tags derived are from those version numbers. This code is targeted for public release on March 1. However, there has been some question about numbering for the release version. Based on a post by Martin Buchholz, my proposal and rationale follows.

The version number of the next stable release will be 22.0 if either Ben Wing's work to implement Mule on the Windows NT platform or Bill Perry's port to the GTK platform is incorporated in the release distribution. If both features fail to be integrated, the release version will be 21.4.

Rationale

We would like to introduce a consistent numbering system which satisfies the following criteria:

• The development and stable versions are easily recognizable from their version numbers.
• Stable versions will start at "patchlevel 0" so that (to some extent) the degree of stability can be estimated from the patch level.
• The patchlevel in the development series can increase to fairly large values, so that ``release tagging'' can be frequent in the development series.

The numbering system will not provide for a clear distinction between ``beta releases'' and ``prerelease tests.'' Experience shows that it is rather difficult to judge when a ``release candidate'' is a serious candidate, and when it is wishful thinking or aggressive marketing by a release manager.

Martin Buchholz's suggestion is to use the convention that even minor versions are stable, odd minor versions are development. This system satisfies the three desiderata above, and is becoming popular. Linux and Perl at least are using this model.

Admittedly, this leaves a ``hole'' at 21.3. So be it. Emacs has plenty of version number mysteries already. One more should not be unacceptably confusing.

More precisely: Minor numbers will be odd for the development series of releases. Patchlevels will be incremented at the discretion of the Beta Release Maintainer. Currently this implies a release including generation of tarballs. The next Beta branch will be opened early in the prerelease period, numbered 21.5. If the major features work out as expected, the new development branch will be renamed to 22.1 at release of the current code.

Minor numbers will be even for the stable series of releases. Patchlevels will be incremented at the discretion of the Stable Release Maintainer, when he releases a new set of tarballs.

Numbering FAQ

Q.1 You're just bumping the major version to stay ahead of the GNU Emacs mainline, aren't you?

Actually, we're not. True, GTK XEmacs and the Mule on NT improvements are not backward incompatible in the sense that they simply have no equivalent in XEmacs 21.1. But these features are, we hope, going to elicit a lot of new code that simply would be pointless in the old environment. For these users, 21.1 will be obsolete.

Q.2 Well, then, you're releasing now in a big hurry just because the GNU Emacs mainline is about to release.

Of course there's some truth to this. The justification for this fork is that we can try things independently of the mainline, things that the mainline might not get around to or is philosophically biased against. If we stand still, we will become obsolete.

But in fact the timing was determined by the availability of certain core developers with the time and energy to push through a release. And all of these core workers happened to have scheduling constraints that strongly encouraged a target date late in the first quarter.

Q.3 Why is it that the URL contains ``21.2,'' but the proposed release version is ``22.0'' or ``21.4''?

URLs should be persistent. If we chose an URL based on ``22.0'' or ``21.4'' we would be risking the choice between renaming an URL, and an URL with no relation to the release. The current development branch is 21.2, and all the test releases will be numbered 21.2.xx. This way, there's a weak mnemonic relationship between the URL and the code.