Before the release

Becoming a release manager

1. Announce your intention to be a release manager to the rox-devel mailing list, stating which program(s) you want to manage.
2. Make a release...

Preparing for the release

1. A few days before the release, announce the release date on the Mailing Lists.
2. Developers commit any outstanding changes they want in the new release.
3. Ensure the manual is up-to-date.
4. Announce code freeze (except for bug fixes).
5. People Using Subversion versions test the code.
6. Translators will also check in their changes during this time. Some translators don't commit directly to CVS; they will send their patches for you to apply manually.

Creating the release archive

To actually create the archive that people will download:

1. Check the program out from subversion (or svn update your copy if you already have it). E.g.:
   

   $ svn co https://svn.sourceforge.net/svnroot/rox/trunk/Archive

2. Fetch the svn changelog and summarise the changes in the Help/Changes file.
   

   $ svn log https://svn.sourceforge.net/svnroot/rox/trunk/Archive

   Note that this lists all changes ever, so remember to stop when you've gone back as far as the previous release! You can also combine multiple commits into one entry (e.g. "Added new feature", "Oops - forgot to commit a file", "Fixed bug in new feature", etc can just be "Added new feature"). If you need more information for a message like "Updated", svn log -v will tell you which files were changed.

3. Update the version number and date in AppInfo.xml, the injector feed XML file (e.g. Archive.xml), and the Help/Changes file.
4. Commit your changes.
5. Run the rox-release script from the directory where you want the release files to be created. The argument is the path to the injector feed in the SVN checkout of the program you are releasing:
   

   $ svn co https://svn.sourceforge.net/svnroot/rox/trunk/rox-release
   $ 0alias rox-release rox-release/ROX-Release.xml
   $ cd .../releases
   $ rox-release .../Archive/Archive.xml
   

6. Diff against the previous release (xxdiff is good). Look out for missing files, or debugging statements that slipped in:
   

   $ xxdiff archive-1.1 archive-1.2

7. Check the program runs. Try with a translation too:
   

   $ LANG=fr ./Program/AppRun

8. Upload the tgz file somewhere and request sign-off from the program's maintainer.

Making the release

Uploading the archive

1. The maintainer will send you a detached GPG signature for the archive.
2. Create some release notes (this is basically just this version's section of the changelog, but sorted by function rather than by date).
3. Go to Source Forge's file release system and:
   • Create a new release. New release name is just the version number part, not the whole program name.
   • Upload the archive and signature.
   • Set changelog, release notes, etc.
   • Set the file formats. The format for the signature is Other.
4. Download archive and signature from file release system. Check signature matches:
   

   $ gpg program-x.y.z.tgz.sig

5. Edit the program's web page (you can get to it from the software index page). Set the Current testing version to the new release's version number. The program will now automatically show up in the Testers wanted box on the news page.

Announcing the release

1. Add the release to the Zero Install (AddApp) feed (if any), marked as testing.
2. Click on the announce this release link at the bottom of the program's web page (it's next to the add new comment link) and enter a short paragraph about what changed. If you keep to plain text and write in the 3rd person, you can reuse this text for the freshmeat announcement later!
3. Do the Send Email Notification on the file releases page.
4. Send a release annoucement to the mailing lists (your new web announcement includes an automatically-generated message suitable for emailing to the list).
5. Make a http://freshmeat.net release announcement.
6. Update any other places that seem interesting (ROX-Filer announcements also go to the news:comp.sys.acorn.announce newsgroup and http://gnomefiles.org).

Marking as stable

1. After a week or so with no major problems, update the page by moving the version from the testing field to the stable field.
2. Update the Zero Install interface file in the same way.