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 (update1)
(https://bitbucket.org/giszmo/glob2 again)
 
(9 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Message|Some permissions needed|The following guide assumes that you have upload ability to savannah (you will need to be a group member), and write access to Mercurial (contact Nct if you need a username and password access). If you don't have these, then you probably arn't allowed to make releases :P}}
==Test phase==


== Planning a release ==
* 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/


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.
Note: Normal glob2 development can take place in the main branch (i.e. master) as usual.

* 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 ==
* Now announce that you branched off the release candidate and that everyone who wants to help testing or fixing it must do:


* 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 release-rc glob2 glob2_release
hg clone https://bitbucket.org/giszmo/glob2
# cd glob2_release
cd glob2
# hg update tip
hg update -r default
hg branch beta<nowiki>[number]</nowiki>-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 [[Changes|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<nowiki>[number]</nowiki>-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:
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.
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<nowiki>[number]</nowiki>-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
* Put a line like: "Changes in <release tag> (release soon)" under "Changes since latest release" in: [http://globulation2.org/wiki/Changes Changes]
;Note 3: Normal glob2 development can take place in the main branch (i.e. default) as usual.
* 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==
== 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 ===
Here is a detailed description of the remaining release process applied for all the alpha releases:
* If the testing above was successfull, run 'scons dist' to create a tar.gz package.
* [[Uploading_to_Savannah|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" ;-)


[[Category:en]]
# Go into the directory containing glob2 the release candidate
# Check that the local mercurial is up to date (through "hg pull && hg update")
# Check that all the required graphics and maps are in the server (through "./mkdata" and "./mkmap")
# Run "make distclean"
# 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
# Run "./bootstrap"
# Run "./configure"; if any problem occurs, well, the release candidate is 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!
# Run "hg tag RELEASE_NAME", in order to tag the Mercurial so that packagers can fetch this *exact* source tree for this release
# Run "make dist" to make the .tar.gz
# Run "fakeroot debian/rules binary" to make the debian package
# [[Uploading_to_Savannah|Upload them to Savannah]] in the folder relating to their version (for example, alpha22 = 0.8.22/).
# Send a mail to the ml, update web site, savannah news, and rest of the Worlds about the "Good news" ;-)
[[Category:Developer Resources]]
[[Category:Developer Resources]]

Latest revision as of 19:34, 4 October 2012

Some permissions needed: The following guide assumes that you have upload ability to savannah (you will need to be a group member), and write access to Mercurial (contact Nct if you need a username and password access). If you don't have these, then you probably arn't allowed to make releases :P

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" ;-)
Misc