Difference between revisions of "Release checklist"

From Bitfighter
Line 20: Line 20:
 
#* Run script found in bitfighter-tools repo to build and upload source tarball
 
#* Run script found in bitfighter-tools repo to build and upload source tarball
 
#* Test downloads
 
#* Test downloads
# Build for various Linux distros using Open Build Service (or tell other distros about the new release.)  Link:  https://build.opensuse.org/package/show?package=bitfighter&project=games
+
# Build for various Linux distros
# Flag old package as being out of date on Arch: https://aur.archlinux.org/packages/bitfighter/
+
#* Use Open Build Service (or tell other distros about the new release.)  Link:  https://build.opensuse.org/package/show?package=bitfighter&project=games
# Post code to static URL: http://bitfighter.googlecode.com/files/bitfighter-latest.tar.gz
+
#* Flag old package as being out of date on Arch: https://aur.archlinux.org/packages/bitfighter/
# * Note for next release: "That way, you can ask the maintainer to point the pkgbuild to the http://bitfighter.googlecode.com/files/ … est.tar.gz and it will always be the newest version whenever someone installs through AUR.  That would bypass the need for communication between dev <-> maintainer to update for every release."
+
#* Post code to static URL: http://bitfighter.googlecode.com/files/bitfighter-latest.tar.gz
 +
#** Note for next release: "That way, you can ask the maintainer to point the pkgbuild to the http://bitfighter.googlecode.com/files/ … est.tar.gz and it will always be the newest version whenever someone installs through AUR.  That would bypass the need for communication between dev <-> maintainer to update for every release."
 
# Rebuild any servers that need rebuilding
 
# Rebuild any servers that need rebuilding
 
# If necessary, add a new line in the master server config file (master.ini - it will reload itself automatically)
 
# If necessary, add a new line in the master server config file (master.ini - it will reload itself automatically)

Revision as of 07:15, 1 March 2013

  1. Make sure all code is checked in to HG
  2. Update checkIfThisIsAnUpdate() in main.cpp and add any update tasks
  3. Update version.h:
    • Change ZAP_GAME_RELEASE to new version
    • Change BUILD_VERSION to (current commit number + 2) (found by running 'hg summary')
    • If new client-server is incompatible with the old, update CS_PROTOCOL_VERSION
    • If new client-master is incompatible with the old, update MASTER_PROTOCOL_VERSION
  4. Re-checkin to HG, so version numbers are correct, and everything aligns correctly NOTE THAT THE TAG WILL COUNT AS A VERSION!
  5. Tag the release in HG. Use format "bitfighter-016"
  6. Build for Windows:
    • Compile the game with the release version
    • Run NSI to create windows installer
    • Test installer
  7. Build for Mac
    • Build the DMG target in XCode
    • Test DMG
  8. Upload to Google Code
    • Upload Windows version to Google code
    • Upload Mac version to Google code
    • Run script found in bitfighter-tools repo to build and upload source tarball
    • Test downloads
  9. Build for various Linux distros
  10. Rebuild any servers that need rebuilding
  11. If necessary, add a new line in the master server config file (master.ini - it will reload itself automatically)
  12. Update auto-update file (/var/www/html/files/getDownloadUrl.php) on master server
    • Update versions/dates
    • Sign the Mac files with our private key for the Sparkle updates
  13. Update bitfighter website
    • Add new release to all releases page
    • Update download page to show new release
    • Add story to main page on website announcing new release
    • Update luadoc/doxygen
  14. Post announcement in forums
  15. Announce new version via email
  16. Post the update to gaming web sites