Difference between revisions of "Releasing a new version"

Planning a release

Globulation2 is developed in a very open way concerning release cycles and versions maintained. Since using Mercurial it became easier to keep older versions updated as committing bugfixes there and merging them up the ladder to default is very easy.

• 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 within days go into the test phase

Test phase

• branch off a release candidate which must be used for testing and bugfixing only - and finally will be released:

hg clone https://bitbucket.org/giszmo/glob2
cd glob2
hg update -r default
hg branch beta[number]-rc

• Increment version number in SConstruct (find and edit env["VERSION"])
• Run these 3:

scons
scons install
scons dist

• make sure all three work (compile, install, and package). If that works, then commit and push your changes
• Adjust the Changelog
• Now announce (on the mailing list) that you branched off the release candidate and that everyone who wants to help testing or fixing it can do the following:

hg clone https://bitbucket.org/giszmo/glob2
cd glob2
hg update beta[number]-rc

• Now wait for the go of all relevant developers and make sure, all cases are tested in depth including
  • custom maps
    • with all AIs and
    • all maps played
  • map editor and
    • playability of those maps
  • tutorial and
  • campaign
  • LAN and YOG both with
    • more than two players and with
    • all major systems (Linux, Mac and Windows preferably
    • both 32bit and 64bit) involved.
  • ...

Note 1

Bugfixes should go into the oldest maintained branch having that bug and then be merged up into later branches like this:

hg update beta1-rc #beta1-rc is defninitely not supported anymore. Decide for yourself where you want to have the bug fixed.
<fix what is wrong>
hg commit -m"bugfix ..."
hg update beta2-rc
hg merge beta1-rc
hg commit -m"merge"
...
hg update default
hg merge beta[number]-rc
hg commit -m"merge"

Note 2

hg update tip is almost always a bad idea after having pulled. tip might be some random branch. Use the branch name when using update. If using

Note 3

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

Release phase

Testing

• Pull a new copy of the release branch:

hg clone https://bitbucket.org/giszmo/glob2
hg clone -r release-rc glob2 glob2_release
cd glob2_release
hg update tip

• Clear:

scons -c

• Compile somewhat optimised:

scons CXXFLAGS="-O2 -g"

• if any problem occurs, then the release candidate is not ready for release! (the final release could be compiled without the -g and with -O3 but right now -g -O2 is a reasonable trade-off between speed and debugability)
• Install:

scons install

• if any problem occurs, then the release candidate is *still* not ready for release!
• Test the resulting installed:

gdb glob2

• if any problem occurs, then the release candidate is nearly ready for release, but too buggy to go out right now, wait another day or two! Never ever feel pressed to get out a release within hours or days. If You have bugs making this release worse than the last one for some players, you may make those players leave glob2 and you cause a lot of trouble getting things straight later. The transition between 2 versions is always a problem and the better the new version the faster this transition will be.

Releasing

• If the testing above was successfull, run 'scons dist' to create a tar.gz package.
• Upload it to Savannah in the folder relating to their version (for example, alpha22 = 0.8.22/).
• Send a mail to the development mailing list, update the wiki, update savannah news, and tell rest of the world about the "Good news" ;-)