XEmacs -- Emacs: The Next Generation
     Searching XEmacs
Quick Links About XEmacs Getting XEmacs Customizing XEmacs Troubleshooting XEmacs Developing XEmacs

XEmacs Release Plan for Late Q1 2001

Revised: 29 March 2001

This is the current revision of the Release Plan for XEmacs 21.4. It describes how the release will be managed and implemented. This version emphasizes current status.

For historical interest, the original draft as submitted to the XEmacs Review Board on 19 December 2000 is here. Other history is in the ChangeLog and CVS.

Currently known bugs and their statuses are in Bug Status.

Plans are being made for a release of version 22.0, including many improvements as well as integration of those features which were not ready for 21.4, to be made in 3d quarter.


This document is maintained by the Release Manager, Stephen J. Turnbull <stephen@xemacs.org>. It should reflect the current policy of the XEmacs Review Board closely. I have tried to incorporate as much as possible of the comments and discussion to date, but errors and omissions surely remain. The responsibility for errors is mine alone.


It's time for a release. What more can we say?

The theme of this release will be consolidation and integration of current projects.

Target date: 1 March 2001

The schedule has slipped three times, first to March 15, then to March 26, and now the release is scheduled for April 15. I said ``it cannot slip anymore,'' but it did. Newbie release manager, what can I say? The code is ready, and now the management is too.

This is a very ambitious target. As mentioned above, a couple of the major features are not going to be ready. Although this is disappointing, there are many small improvements, along with a couple of major features (such as native widgets and the net installer for Windows, both due to Andy Piper). We hope you will find XEmacs 21.4 a substantial improvement over XEmacs 21.1.

And of course many new packages have been added over the months since 21.1 was released. Some of these use the new features in 21.4.

The Public Release Manager

I have volunteered to act as Public Release Manager as an explicitly term-limited position, and have been accepted by the Review Board. The term of the Public Release Manager is up when Vin (or his successor) accepts handover of the release as "stable." The Public Release Manager will be responsible for tracking progress, publicity, and announcing and enforcing feature freeze. Further details are in the job description.

The Public Release Manager may of course delegate any of these responsibilities; he just has to make sure they get done. In particular, Martin will continue to actually roll the tester tarballs. Thank you, Martin!


Yes, please! Right over here.

Features/projects proposed for the 21.4 release

This is a short list of projects proposed for the 21.4 release. Each has an abstract more or less suitable for NEWS (draft version now available), and a brief status indication. For details, including checkout, configure, and test procedures, follow the links provided. They are more or less ordered by size (big, risky ones first).

XEmacs on the GTK platform: Bill Perry

XEmacs has been ported to the GTK platform. The basic text editor still uses native X11 features to implement buffer redisplay and so on. However, it is now possible to use the GTK and GNOME widgets (such as dialogs and toolbars) to implement GUI components in XEmacs. It is an optional feature, and not included in the default configuration.

The GTK support is being added on a branch from the 21.2 code base. It may be checked out and tested. After a short period, it is planned for merger (now complete!) to the main code branch, but its status is experimental and unsupported. (If you were hoping for a miracle, it didn't happen. GTK/XEmacs is still experimental and unsupported. But sometimes it really works and looks good!)

Testing will be aimed at making sure it does not have negative impacts on other platforms; neither failure to build nor catastrophic data loss will be considered a ``showstopper'' if GTK is configured in to XEmacs.

Mule on Windows: Ben Wing

Windows has a well-elaborated interface for internationalization. Mule is being ported to that environment.

This code is currently incomplete, and neither builds nor runs. It will not be included in the March 1 release. It is in the process of being added as a branch in CVS, and procedures for checking it out and testing it will be announced when that is done.

Portable dumper: Olivier Galibert

The portable dumper is a subsystem that replaces the traditional ``unexec'' method of creating an Emacs pre-loaded with Lisp code and data. The traditional method actually ``dumps'' the core image of the executable to a file, then adjusts the file so that it can be executed by the operating system, restoring the execution state. The portable dumper executes Emacs as usual, then reloads the Lisp code and data very quickly from a specially formatted dump file. This is not as fast as the unexec method, but it requires much less knowledge of the operating system, and is thus more portable and maintainable.

This code has been merged to the release code base and in active test for some months.

Gutters and native widgets: Andy Piper

Gutters are GUI components of an XEmacs frame. They can hold arbitrary text. This text does not change with buffer motion. There is one gutter on each edge of the frame. In theory scrollbars, menubars, and toolbars could be placed in the gutter instead of being given special status.

Native widgets are conceptually unrelated, but were convenient to implement at the same as the gutters. Instead of implementing GUI widgets via image glyphs and Lisp code, native widgets are implemented using the underlying GUI.

This code has been merged to the release code base and in active test for some months.

Custom themes: Jan Vroonhof

The Customize interface provides a flexible way to document configuration variables, and reset them with varying degrees of permanency. Custom themes intend to extend this flexibility to groups of related settings that tend to be correlated (either for a priori reasons or as a matter of typical tastes of users).

Theme support requires certain hooks in the core Lisp, and may be considered a major new feature. However, most of the code will be implemented as an add-on package at first. It is very likely that it will be integrated into the core in the following release.

Currently incomplete, but because of the package development strategy there is a good chance it can be released at about the same time as the 21.4 core. (Note: Jan has not reported or been active recently, and the status of Custom themes must be considered dubious.)

CCL improvements: Hisashi Miyashita

Improvements to the Code Conversion Language (CCL) and its interpreter.

This code is unconditionally built in. It has been merged to the release code base and in active test for some weeks.

Mule case tables: Yoshiki Hayashi

Improvements to the case tables, especially making them work on Mule.

This code is unconditionally built in. It has been merged to the release code base and in active test for some weeks.

Syntax table improvements: Matt Tucker

Syntax table improvements.

This code is unconditionally built in. It has been merged to the release code base and in active test for some weeks.

PostgreSQL Lisp interface: Steve Baur

Emacs Lisp interface to PostgreSQL. This is PostgreSQL-specific.

PostgreSQL development suopprt is autodetected, and if found this code is built in by default. It has been merged to the release code base and in active test for some months.

SUMO integration: Stephen Turnbull (Volunteers eagerly sought!)

We should reverse Steve Baur's decision to not distribute the SUMO Lisp in the main tarball. The packages are popular, but the typical user of the core tarball wants the kitchen sink.

MS-Windows printing support: Kirill 'Big K' Katsnelson

Printing support as Windows users expect it.

Kirill has said this is mostly done, but hasn't reported on XEmacs Beta recently.

Mr. Preprocessor's miscellaneous projects: Michael Sperber
  • complete the init-file migration/back-migration code
  • complete the movemail/locking integration
  • fix some build issues, for example the recent path-searching bug report, and the pdump thingie.

Asynchronous projects

An asynchronous project is one which will be publicized along with the release of the core code, but is under the control of the taskmaster, not the Release Manager. These projects may involve installable Lisp packages or separate binaries. They are supported by XEmacs.org, but a problem in an asynchronous project will not be a considered a ``showstopper'' for the rest of the release.

Documentation: everybody.

Documentation. I hope there will be lots of documentation added! Documentation is always badly needed. Some of our documentation is buggy, other parts have become incorrect through changes in the functionality they describe. Many features are simply not described at all.

It's not hard to write documentation correctly. Please give it a try!

Even if you're uncomfortable writing docs, inaccurate or missing documentation is a severe hindrance to users, and we consider that a bug. Please report any problems you have with the documentation.

Cygwin netinstaller for XEmacs on Windows: Andy Piper
The Cygwin netinstaller has been ported to XEmacs. This will be mentioned in the release NEWS. Otherwise it will be treated as "not part of the core" for the purposes of feature freeze in the same way that packages aren't part of the core. Available in betas now (since 21.2.40).

Projects not to be included in the 21.4 release

A number of projects are or have recently been active in XEmacs.org, but are not planned for inclusion in this release. See the list of planned features. There are three possible reasons:

  1. Coding is not complete.
  2. The author is not available to work on the feature during the prerelease period.
  3. The Release Manager has incorrect information about the state of the code or availability of developers to work on the code.

For a short period, status of these projects (to be included or omitted) may change at the discretion of the Board of Reviewers. Suggestions or status inquiries may be sent to the Release Manager or to the Developers' Mailing List.

Other projects seem to be completely inactive.


A lot of people have presented ideas for improving XEmacs. Two lists that I think are interesting are

  1. Ben Wing's Architecting XEmacs which describes general directions for improvement, with some design suggestions, and
  2. Jamie Zawinski's xemacs wishlist which describes practical features that can be implemented independently of improvements in the core in most cases.

Your suggestions, both direct and for links to pages about desirable features for XEmacs, are welcome.


Note: I believe this now reflects current status. It is important that we decide the default configuration for test releases soon. Martin or I will present RFCs to the Review Board shortly.

December 19:

Submit draft proposal to the board; request detailed status reports from PWPs; feature slush/RFP to board. RFP means no completely new features, only features with some history of discussion, design complete, and preferably prototype code, are acceptable. Status on 1 February: complete.

January 2:

Post revised draft on www.xemacs.org; RFC to xemacs-beta; nag PWPs. Status on 1 February: complete (lack of response from some PWPs means their projects are currently orphaned).

January 9:

Close board-level RFPs == full feature freeze; re-revise and post release proposal on comp.emacs, comp.emacs.xemacs; post known bug/issue list to www.xemacs.org. Status on 1 February: public announcement made on 11 January, feature freeze in place, known bug/issue list ... uh what did you say again?

January 11 (new):

Decide details of default configuration for prerelease versions, and schedule of changes, if any.

January 16:

Open new development branch in CVS. Weekly tarballs that build and run from now until release. Bug/issue list updated at least weekly. Status on 1 February: development branch delayed to approximately 5 February; issue list mea maxima culpa. Weekly tarballs: on schedule. All hail Martin!

February 1:

Code expected to be complete. Interim reports from PWPs; triage the features. Reports emphasize known issues for testers to bang on. Status on 1 February: err, sorta.

February 1:

Implement default configuration for testing. Announce explicit testing goals (bugs, issues, features) to xemacs-beta. Update frequently. Status on 1 February: likely delayed to 5 February.

February 15:

Final reports from PWPs: code complete and design bugs cleared. Triage features not meeting this criterion. Status on 1 February: on schedule.

March 26:

The original target date has slipped twice. That's life. So we'll do the release on March 26.

Didn't happen. Oh, well.

April 15:

The original target date has slipped three times. Sigh. This is called ``learning by doing.''

"Release" 21.4.0 as "gamma". Branch 21.1 off trunk, move devel code to trunk as 21.5, open 21.4 as new stable branch. 21.1 will continue to be supported as the "stable" branch, with hopefully no more releases until:


Acceptance of 21.4.x as stable by Vin; mothball 21.1.


Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML