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

Releasing a new version

From Globulation2

Revision as of 07:33, 29 July 2007 by K776 (talk | contribs) (update1)
Jump to: navigation, search

Test phase

  • First thing to do when planning a release is to propose it. Email the development mailing list and say you think a release should be made.
  • If no-one complains branch off a release candidate which must be used for testing and bugfixing only - and finally will be released:
# hg clone http://hg.globulation2.org/glob2/
# hg clone -r master glob2 glob2_release
# cd glob2_release
# hg update tip
# hg push -r release-rc https://hg.globulation2.org/glob2/

Note: Normal glob2 development can take place in the main branch (i.e. master) as usual.

  • Now announce that you branched off the release candidate and that everyone who wants to help testing or fixing it must do:
# hg clone http://hg.globulation2.org/glob2/
# hg clone -r release-rc glob2 glob2_release
# cd glob2_release
# hg update tip

Note: Although pushing fixes to both branches (master and the new release-rc) isn't nessesary, it is probably wise to, so as to avoid conflicts later when merging.

  • Put a line like: "Changes in <release tag> (release soon)" under "Changes since latest release" in: Changes
  • Increment version number in configure.in
  • Increment Debian version number by doing debchange -i in debian/ (this must be done by nct on the mailing list)
  • Do a release dry run, i.e.: all the release steps below except the "hg tag" and only propagate news about a release candidate - not a release.
  • 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 mercurial is up to date (through "hg pull && hg update")
  3. Check that all the required graphics and maps are in the server (through "./mkdata" and "./mkmap")
  4. Run "make distclean"
  5. Set CXXFLAGS to "-O2 -g $CXXFLAGS", final release could be compiled without the -g and with -O3 but right now -g -O2 is a reasonable tradeoff between speed and debugability
  6. Run "./bootstrap"
  7. Run "./configure"; if any problem occurs, well, the release candidate is not ready for release!
  8. Run "make"; if any problem occurs, well, the release candidate is *still* not ready for release!
  9. Test the resulting binary; if any problem occurs, well, you should fix your code instead of releasing stuff!
  10. Run "hg tag RELEASE_NAME", in order to tag the Mercurial so that packagers can fetch this *exact* source tree for this release
  11. Run "make dist" to make the .tar.gz
  12. Run "fakeroot debian/rules binary" to make the debian package
  13. Upload them to Savannah in the folder relating to their version (for example, alpha22 = 0.8.22/).
  14. Send a mail to the ml, update web site, savannah news, and rest of the Worlds about the "Good news" ;-)
Misc