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 (final update)
(https://bitbucket.org/giszmo/glob2 again)
 
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Warning|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}}
{{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}}

== 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.


==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.
* 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
* 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/
== Test phase ==
hg clone -r master glob2 glob2_release

cd glob2_release
* branch off a release candidate which '''must''' be used for testing and bugfixing '''only''' - and finally will be released:
hg update tip
hg clone https://bitbucket.org/giszmo/glob2
cd glob2
hg update -r default
hg branch beta<nowiki>[number]</nowiki>-rc
* Increment version number in SConstruct (find and edit env["VERSION"])
* Increment version number in SConstruct (find and edit env["VERSION"])
* Run these 3:
* Run 'scons', 'scons install', and 'scons dist' and make sure all three work (compile, install, and package). If that works, then push the new branch using:
scons
hg push -r release-rc https://hg.globulation2.org/glob2/
scons install
* Put a line like: "Changes in <release tag> (release soon)" under "Changes since latest release" in: [[Changes]]
scons dist
* Now announce (on the mailing list) that you branched off the release candidate and that everyone who wants to help testing or fixing it must do the following:
* make sure all three work (compile, install, and package). If that works, then commit and push your changes
hg clone http://hg.globulation2.org/glob2/
* Adjust the [[Changes|Changelog]]
hg clone -r release-rc glob2 glob2_release
* 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:
cd glob2_release
hg clone https://bitbucket.org/giszmo/glob2
hg update tip
cd glob2
* Now wait about a week for all bugs to be found and fixed in the release-rc branch.
hg update beta<nowiki>[number]</nowiki>-rc
Note 1: 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.
* 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 2: Normal glob2 development can take place in the main branch (i.e. master) as usual.
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
;Note 3: Normal glob2 development can take place in the main branch (i.e. default) as usual.


== Release phase ==

==Release phase==
=== Testing ===
Here is a detailed description of the remaining release process applied for all the alpha releases:
===Testing===
* Pull a new copy of the release branch:
* Pull a new copy of the release branch:
hg clone http://hg.globulation2.org/glob2/
hg clone https://bitbucket.org/giszmo/glob2
hg clone -r release-rc glob2 glob2_release
hg clone -r release-rc glob2 glob2_release
cd glob2_release
cd glob2_release
hg update tip
hg update tip
* Clear:
* Run 'scons -c'
scons -c
* Run '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 tradeoff between speed and debugability)
* Compile somewhat optimised:
* Run 'scons install'; if any problem occurs, then the release candidate is *still* not ready for release!
scons CXXFLAGS="-O2 -g"
* Test the resulting installed with '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!
* 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)
===Releasing===
* 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.
* 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/).
* [[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 Worlds about the "Good news" ;-)
* 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]]
[[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