While looking at the wiki, I noticed the following page:
http://wz.rootzilla.de/wiki/user:release_checklist
This might be extended to some general SVN guidelines, like:
"On every check-in:
- Check if your changes compile and run
- If you're not sure about other systems, add that to the log message
- Modify the ChangeLog according to your changes, if necessary
- Check in one change at a time
- Check what you check in ("svn diff | diffstat", "svn diff")
- Write a descriptive log message: For new features, describe how to
use them, list possible problems
For larger changes:
- Make a branch in SVN (one branch for one feature)
- Check in often, the branch must not be stable (but bear in mind the
next point)
- Merge every new trunk revision into your branch and fix conflicts, to
ease merging back into the trunk
- When your changes have stabilized merge back into the trunk
For a release:
- Make a new tag for the release
- Prepare a release candidate:
- Run ./autogen.sh and add the generated/modified files to SVN
- Edit configure.ac, win32/warzone2100.rc (other files?) to include the
correct version
- Make a source tarball, autopackage, Windows installer
- Announce it on the mailing list, forum, home page, web sites:
- linuxgames.com
- happypenguin.org
- freshmeat.net
- linux-gamers.net
- If there are bug reports, fix (and possibly merge the fixes into the
trunk as well) and repeat
- Else: Release.
- If a serious bug is found, fix and make a bugfix release (with a
letter appended to the version number)"
I have changed the release procedure a bit. My goals:
- Make a tag to release from so development can continue on the trunk
without destabilizing the release
- What's in SVN gets into the tarball, so checking out the tag is equal
to getting the tarball
The last revision of the tag is the best version of the release, and
ideally the release itself.
So lets say we want to release 2.0.6:
- Make tags/2.0.6
- Release 2.0.6-rc1
- Fix bugs
- Release 2.0.6-rc2
- No bugs found
- Release 2.0.6
- Fix an important bug
- Release 2.0.6a
For the next round copy the trunk to tags/2.0.7.
About the branches, we have SVN, so lets use it. Having a branch instead
of developing solely on ones hard disk has (at least) two advantages:
- Changes can be checked in often, so the patches are small compared to
one complete patch adding a new feature (useful for bug fixing)
- People can test the branch and report problems earlier
--
BOFH excuse #250:
Program load too heavy for processor to lift.
_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev
