How to make a release

From OHRRPGCE-Wiki
Jump to navigation Jump to search

Stable releases of the OHRRPGCE have often happen rather chaotically. This article is an attempt to plan a cleaner process for future releases.

  • Announce the approach of a release on the mailing list and the forums
  • Declare the current nightlies to be release candidates
    • Wait for the testers have had enough time to find bugs in the release candidates and the developers have had time to fix them in the wip. (1-2 weeks?)
  • Create the stable branch
    • First make sure that whatsnew.txt is updated with all the appropriate info.
    • Actually create the branch. (For cleanest results it may help do do this in a brand new clean working copy)
    • Change the release codename and branch revision in codename.txt
    • Run docs/update-html.sh on the new branch.
    • Update dates in whatsnew.txt README-game.txt and README-custom.txt (don't forget to update whatsnew.txt on the wip trunk also!)
  • Build and upload the release binaries for each platform (James has Virtualbox VMs suitable for these)
    • run release/release-linux-x86.sh on 32bit Linux
    • run release/release-linux-x86_64.sh on 64bit Linux
    • run release/release-win.bat on Windows
    • run release/release-mac.sh on Mac (compiles both 64 bit and 32 bit)
    • run release/release-android.sh on 32bit Linux
  • Check that all the new release files are in https://hamsterrepublic.com/ohrrpgce/archive/
  • Download and test each of them on the appropriate platform
  • Officially declare the release stable.
    • run release/release-docs.sh on Linux
    • (Requires login to hamsterrepublic.com webserver) run script/ohrstable.sh to update the web server symlinks to point to the newest files.
    • Update the wiki
  • Double check for any fixes on the branch that still need to be copied over to the wip trunk.
  • Announce the release
    • In the Forums
    • Make a post in the ohrrpgce facebook group
    • Tweet about the release with #ohrrpgce
  • Any further fixes on the branch can go in a +1 release at some later date
  • Update the bug tracker (major releases only)
    • Create a label for the release
    • Re-tag any open bugs tagged 'nightlies' with the label for the new release
    • Create a milestone for the next release (with a temporary name if needed)
    • Move any open bugs for the previous release milestone (the unfinished todo list) to the new milestone