Releasing Slash'EM

Back to the Slash'EM homepage

Preparing for release

Before releasing Slash'EM, you should send an email to the slashem-devel mailing list at least a week in advance proposing a release date. This allows developers to request a delay and to plan their work around the freeze that occurs on release days.

On release day edit readme.txt and add the date (as Month day/year) of the release and your name as release technician. Commit this with a comment such as "Preparing for 0.0.6E4F8 release".

Creating a tarball

The next step is to create a tarball for final testing. This is done using the release scripts (contact Ali for details) or in the worst case you can wait for Ali's preview system to create a tarball (which uses the same scripts).

Check the diffs from the previous released version and make sure that no unexpected changes have been introduced. The release scripts also create a set of diffs which represent the automatic fixups which it believes should be performed. You can ignore diffs which only change RCS IDs. These don't represent real differences.

At the very least, you should check that the tarball builds correctly on at least one platform and that you can start a game, save it and restore again. Stable releases should be tested on as many platforms as practical and have a quick ascension in wizard mode to make sure they are not completely broken.

If you are able to put the release candidate up on a website somewhere and let people on #slashem on irc.freenode.org know so that anyone who wants can do their own tests at the same time, then that would be ideal.

Writing the blurb

Because release announcments are made in a number of different places and in a number of different formats, you may find it helpful to write some boilerplate that can be reused for these. I usually write the following:

Making the release

Once the release candidate has passed the various tests, the versions of the source files included in the tarball need to be tagged so that we could re-create the tarball if needed. This is done with the following command: 

% cvs tag -R SLASHEM_0_0_7E6F2 .
where SLASHEM_0_0_7E6F2 should be replaced by whatever tag is appropriate for the release you are making.

The tarball can now be released by uploading it to upload.sourceforge.net in the incoming directory (log in as anonymous).

Then go to the sourceforge file release system and add a release to the slashem-source package. The release name should be the bare version number, eg., 0.0.7E6F2.

FRS step 1

The release notes for sourceforge are normally just the first line of the change summary you wrong earlier. The change log can simply be uploaded.

FRS step 2

Select the tarball from the list and add it.

FRS step 3

Set the processor to Any, the file type to Source .gz and update.

FRS step 4

Send monitoring users a notice.

Publicizing the release

Slash'EM homepage

The next step is to update the Slash'EM web pages. For development versions this means adding the change log to devel.html and creating links to all the tracker artifacts. You should note at the bottom of the page which versions (if any) the new release is compatible with. Finally the summary line and the links at the top of the page need to be updated.

News from the homepage which is no longer current should be moved into the archive and an entry made for the new release.

The Slash'EM homepage may be found on shell.sourceforge.net in /home/groups/s/sl/slashem/htdocs

Project summary

A news item should be posted to sourceforge using their submit system. We normally use a subject like SLASH'EM 0.0.7E6F2 released and a text of something like: 

Announcing Slash'EM version 0.0.7E6F2 (development) ...
Version 0.0.7E6F2 is the third beta release of Slash'EM Vampire.
followed by the change log.

The slashem-announce mailing list

You should send an email to the slashem-announce mailing list. This can be identical to the news item submitted to sourceforge with a note at the end as follows: 

Binaries and source are available from the development page:
http://www.slashem.org/devel.html
The Reply-To header should be set to the slashem-discuss mailing list.

rec.games.roguelike.announce

Send a post to rec.games.roguelike.announce and rec.games.roguelike.nethack containing the announcement you wrote above. The Followup-To field should be set to rec.games.roguelike.nethack

Freshmeat

Follow the links from the Slash'EM page to announce a new version. Use the change summary you wrote earlier for the changes box.

The Linux Game Tome

Follow the links from the Slash'EM page to announce a new version. Use the change summary you wrote earlier for the changes box.

Setting up for the next release

The final step is to set CVS up so that development can continue on the next version of Slash'EM. To do this, move the list of changes from readme.txt into history.txt, create a new entry for the next version in readme.txt. Example: 

ver 0.0.7E6F3 [?] [Released by ?]
Then change the version number in patchlevel.h (don't worry about port specific version numbers, they will be dealt with by the port maintainers). Use something like Setup for version 0.0.7E6F3 as a comment.

Slash'EM Dev-team.