Free and Open Source real time strategy game with a new take on micro-management

Difference between revisions of "Releasing a new version"

From Globulation2

Jump to: navigation, search
m (Added tag stuff)
m
Line 1: Line 1:
==Test phase==
In order to allow someone to take care of it, here is a detailed
description of the release process applied for all the alpha releases:


First thing to do when planning a release is to propose it.
# Go into the directory containing glob2 HEAD

If no-one complains branch off a release candidate which '''must''' be used for testing and bugfixing '''only''' - and finally will be released:
# cp -a <old directory name> <new directory name>
# cd <new directory name>
# cvs tag -b <release tag name>-rc

Normal glob2 development takes place in the original HEAD
branch as usual.

Now announce that you branched off the release candidate, that everyone who wants to help testing and fixing it must do:

# cp -a <old directory name> <new directory name>
# cd <new directory name>
# cvs update -r <release tag name>-rc

And also every bugfix must be done for both branches HEAD and the release candidate to avoid cvs merging weaknesses.

Now wait about a week.

==Release phase==

Here is a detailed description of the remaining release process applied for all the alpha releases:

# Go into the directory containing glob2 the release candidate
# Check that the local cvs is up to date (through "cvs up")
# Check that the local cvs is up to date (through "cvs up")
# Check that all the required graphics and maps are in the server (through "./mkdata" and "./mkmaps")
# Check that all the required graphics and maps are in the server (through "./mkdata" and "./mkmap")
# Run "make dist-clean"
# Run "make dist-clean"
# Increment version number in configure.in
# Increment version number in configure.in
Line 10: Line 33:
# Set CXXFLAGS to "-O2 -g -march=i686", final release could be compiled without the -g and with -O3 but right now -g -O2 is a reasonable tradeoff between speed and debugability
# Set CXXFLAGS to "-O2 -g -march=i686", final release could be compiled without the -g and with -O3 but right now -g -O2 is a reasonable tradeoff between speed and debugability
# Run "./bootstrap"
# Run "./bootstrap"
# Run "./configure"; if any problem occurs, well, the HEAD is not ready for release!
# Run "./configure"; if any problem occurs, well, the release candidate is not ready for release!
# Run "make"; if any problem occurs, well, the HEAD is *still* not ready for release!
# Run "make"; if any problem occurs, well, the release candidate is *still* not ready for release!
# Test the resulting binary; if any problem occurs, well, you should fix your code instead of releasing stuff!
# Test the resulting binary; if any problem occurs, well, you should fix your code instead of releasing stuff!
# Run "cvs tag RELEASE_NAME", in order to tag the CVS so that packagers can fetch this *exact* source tree for this release
# Run "cvs tag RELEASE_NAME", in order to tag the CVS so that packagers can fetch this *exact* source tree for this release

Revision as of 21:15, 30 March 2007

Test phase

First thing to do when planning a release is to propose it.

If no-one complains branch off a release candidate which must be used for testing and bugfixing only - and finally will be released:

# cp -a <old directory name> <new directory name>
# cd <new directory name>
# cvs tag -b <release tag name>-rc

Normal glob2 development takes place in the original HEAD branch as usual.

Now announce that you branched off the release candidate, that everyone who wants to help testing and fixing it must do:

# cp -a <old directory name> <new directory name>
# cd <new directory name>
# cvs update -r <release tag name>-rc

And also every bugfix must be done for both branches HEAD and the release candidate to avoid cvs merging weaknesses.

Now wait about a week.

Release phase

Here is a detailed description of the remaining release process applied for all the alpha releases:

  1. Go into the directory containing glob2 the release candidate
  2. Check that the local cvs is up to date (through "cvs up")
  3. Check that all the required graphics and maps are in the server (through "./mkdata" and "./mkmap")
  4. Run "make dist-clean"
  5. Increment version number in configure.in
  6. Increment Debian version number by doing debchange -i in debian/
  7. Set CXXFLAGS to "-O2 -g -march=i686", final release could be compiled without the -g and with -O3 but right now -g -O2 is a reasonable tradeoff between speed and debugability
  8. Run "./bootstrap"
  9. Run "./configure"; if any problem occurs, well, the release candidate is not ready for release!
  10. Run "make"; if any problem occurs, well, the release candidate is *still* not ready for release!
  11. Test the resulting binary; if any problem occurs, well, you should fix your code instead of releasing stuff!
  12. Run "cvs tag RELEASE_NAME", in order to tag the CVS so that packagers can fetch this *exact* source tree for this release
  13. Run "make dist" to make the .tar.gz
  14. Run "fakeroot debian/rules binary" to make the debian package
  15. Upload them to glob2@www.globulation2.org:/home/glob2/public_html/releases/X.Y.Z (for example, alpha20 = 0.8.20).
  16. Send a mail to the ml, update web site, savannah news, and rest of the Worlds about the "Good news" ;-)
Misc