Preparing a new release

Preparing a release takes a bit of time and preparation to be successful. This document will attempt to walk you through the process

1. Generally, to package a release you should be the assigned “driver” or a member of the assigned “driver team” for a series. If you're unsure if you should be making a release, ask.
2. Most (if not all) critical bugs should be fixed for a series before making a releases (it may be acceptable to release betas, release candidates, etc. with known critical bugs). The driver (so maybe you?) will determine if a release will be postponed because of outstanding release critical bugs.
3. Most (if not all) essential specifications should be implemented for a series before making a release (it may be acceptable to release betas, release candidates, etc. without all features implemented). The driver (so maybe you?) will determine if a release will be postponed because of outstanding specifications.
4. Boot and check around to make sure things generally seem to be in good working order.

This file contains quick information to finding more specific and useful information. It also contains the current version number which must be updated.

These two files are the same (make sure they are). It is a letter from whoever is preparing the release (usually) to the end-user. It includes details about what the project is, a personal letter from the author (ie. how the last development cycle went, introduction to new features – you're writing it, you get to decide), info about the team who contributed to this release, list of new features, known issues, plans/goals/todo, and a conclusion. Be creative, fluid, and ensure it is well written.

Run

make clean

in the source directories for the driver(s). Also, ensure there are no binaries in bin/

At this point, you'll want to commit your changes and export.

bzr commit -m "Preparing for release XXX"
bzr export ../sapidlib

XXX would be replaced with the versioning, of course.

This will export the branch into a directory.

1. Move the exported directory into a new directory called sapidlib-XXX (replacing XXXX with the version).
2. Copy out the install script (etc/install.sh) into the newly created directory

3. tar -zcf sapidlib.tar.gz sapidlib

4. rm -rf sapidlib

5. Create a README file that informs the user how to run the install script (or how to set the executable permission with chmod +x).
6. Move up one directory and

   tar -zcf sapidlib-XXX.tar.gz sapidlib-XXX

   (replacing XXX with the version).

You have now packaged sapidlib and you need to test it. The install script should be able to unpack and have the mud configured so that all the user has to do is type ./startmud & in etc/

For the windows package, just take the old windows package and replace lib with the new lib directory. You'll also want to update the documentation such as the release notes and what not. There is no install script to worry about at this time - just package it up with zip.

Once you've created the package and you've _confirmed_ that it has worked, you're ready to make the release.

Before you do anything else, you need to prepare the release announcement. A simple format to follow is:

1. A general description of the project, including what it is, or what it does. This should be no more than a few sentences long, and should start with a one-sentence overview of the purpose of the news item (e.g. a new release, major donation, etc.).
2. A second paragraph should be included as further detail for the news item, that you would like to be seen by all readers of the news item. Usually a paragraph or two is all that is required; keep this concise and include additional information on your project web site (which you mention later-on in the news article).
3. You should provide a listing of URLs that apply to the news article, including links back to the project's latest file releases, the project home page and anything else that may be applicable. Please keep the URLs in long form and do not shorten them via use of a third party URL shortening service.
4. Any further details that are not covered in the prior paragraphs would either belong at the end of the article, in content placed on the project web site, or in a separate news posting.

Next, upload it to all the mirrors (mudmagic, mudbytes, lpuni.org/releases, sourceforge, launchpad, etc.).

Next you'll want to release/post the release announcement everywhere you can (ie. mudmagic, mudbytes, lpmuds.net, themudconnector, google groups, launchpad, our own website, etc. etc.). Get the word out there!! :)