Release Engineering

This guide describes the steps needed to release a version of Stars! Nova. It describes what preparations must be made, how to build the release packages and how they should be published.

Preparation

Code Checks

Check all uses of int.Parse use the two parameter version.This is needed to ensure Nova runs properly regardless of the way thousands seperators and decimal numbers are represented locally. Normally Nova persists strings in the InvariantCulture format:

int.Parse(((XmlText)subnode.FirstChild).Value, System.Globalization.CultureInfo.InvariantCulture);

However item IDs (Keys) may be persisted in Hex format:

int.Parse(((XmlText)subnode.FirstChild).Value, System.Globalization.NumberStyles.HexNumber);

Feature Freeze

Issue a feature-freeze on the version control path that will be used to make the release. This is either trunk or a specific release branch. Ensure that your local working copy is updated to the latest version (or to a specific revision agreed upon for the release) before proceeding.

Version name and year

Open VersionInfo.cs and update the following items:
* AssemblyCopyright: Update year, if needed.
* AssemblyFileVersion: Change to new version number.
* AssemblyVersion: Change to new version number, if needed.

Test the web link

Check the web link on the splash screen is still current. Update it in GlobablDefinitions.cs if requried.

Changelog

Make sure CHANGELOG.txt is updated with the changes that has been made between last release and now. Use the SVN log messages to generate the list of changes and refer to the issue number of bugs and features solved in the new version. This is user documentation so technical code changes that only affect the source code structure and internal design should generally not be included. Changes to publicly documented APIs (map generation, AI, etc.) should be documented.

For the changelog to be formatted properly by SF.net, use max. line length of 65 characters.

Packaging

Binary packages

Windows setup package

Open the '''NovaSetupWindows.sln''' Visual Studio solution file (requires non-Express Visual Studio Edition). In the ''Windows Setup'' project change the ''Version'' property to reflect the new version number and choose ''Yes'' to the dialog box that recommends to change ProductCode so that a new value is auto generated. Make sure the ''Release'' build configuration is selected, go to the ''Build'' menu and click ''Rebuild solution''. The resulting setup package is located in the Setup\Windows\Release folder with the name '''stars-nova-x.y.z-windows.msi'''.

Source package

If you have the 7-zip command line version (7za.exe) and a Subversion command line client (svn.exe) in your PATH environment variable you can run CreateSourcePackage.bat to build the source package. If successful, it will create a '''stars-nova-source.zip''' file in the Build folder. Rename the file to '''stars-nova-x.y.z-source.zip'''.

If you do not have these tools you can create the source package manually. Run SVN export outside you local working copy and export from https://stars-nova.svn.sourceforge.net/svnroot/stars-nova/trunk. Zip the result as '''stars-nova-x.y.z-source.zip'''.

The purpose of SVN export is to get all the files and folders from SVN, but without all the working copy folders (.svn) and SVN properties.

Testing

Follow the [Test Plan] and ensure that the release media works as expected on most platforms. Test newly added features and file bug reports for things that don't work as expected. If no bugs are discovered then you can proceed to the final publishing step. If one or more critical bugs are discovered, then they should be fixed, or the functionality they originate from (if any) must be disable or the shortcoming must be clearly documented. Depending on the severity of the bugs the testing phase may be repeated several times. If a bug requires too much resources to fix it in a timely manner, and it cannot be removed by limiting functionality, then it should be properly documented as a Known Issue so that users are aware of it.

Publishing

Make sure that all changes made in previous steps are committed to SVN. If you have to commit non-release engineering specific changes then make sure that they are entered into the change log if they are relevant to users. This is the point of no return. Once you proceed beyond this point the allocated version number will forever be associated with the release media.

Release

Use the File Manager to upload all release files (source and binary packages) to SF.net together with the change log in a new folder named after the version number. Remember to set the binary packages as the default download for each platform.

Announcement

The release is automatically announced to everyone monitoring the given packages on SF.net. However, the homepage needs to be updated to reflect the new release if applicable.
Publish a news item on the SF.net project site. You might want to try to get the news item on the front page of SF.net. Also check for other places to announce the new version, i.e. the Stars! AutoHost forum and freshmeat.net.

Final steps

Tag

Use SVN to tag the exact version control path and revision that was used to produce the release media. This will produce a snapshot of the source code and content under the version control path '''/tags/x.y.z'''.

New issue tracker group

Users need to be able to register bug reports for the newly released version. Add a new artifact group with the same name as the new version through the bug tracker group admin interface.