Creating a Release

This guide describes all the steps for creating a new release. The process is mostly automated, so this mostly serves as a checklist.

Before Building Packages

• Test! Make sure that things are working well on all the platforms. In order to do this you need a fully functional build on all platforms. You'll need this setup to build the packages as well.
• Update the version number.
  • In build/cmake/CMakeLists.txt, search for the SIRIKATA_VERSION_* variables and update them.
  • See Debian Packaging for how to update the Debian packaging information.
• Commit but do not tag the release.
  • Ideally bumping the version number is the last commit.
  • These commits need to be in a public repository that you can clone them when building packages. One way to accomplish this is to build
  • We don't tag the release until we've got all the packages built and tested so that tags don't become public until they are finalized. If you aren't using the central repository to get the source for building packages, you can safely tag now since the tag can be deleted and changed if necessary.

Building Packages

This step is entirely automated on each platform.

Windows

From a fully functional checkout (i.e. you've built from within the directory and have the latest dependencies) run

   ./tools/release/build-win32-release.bat x.y.z

This depends on a bunch of tools being available in their default locations: CMake and Visual Studio for the build, Python (to run a script that extracts Breakpad symbols), 7zip (for generating the archive).

The version number here is only used for naming the archive, you don't necessarily need a tag or branch with the name vx.y.z. However, this means that you do need to already have the correct revision checked out in your working copy.

This should result in two files, sirikata-x.y.z-win32.zip and sirikata-x.y.z-win32.dbg.zip, sitting in the top directory.

Mac

From a fully functional checkout (i.e. you've built from within the directory and have the latest dependencies) run

   ./tools/release/build-mac-release.sh [--debug] x.y.z

The version number here is only used for naming the archive, you don't necessarily need a tag or branch with the name vx.y.z. However, this means that you do need to already have the correct revision checked out in your working copy.

This should result in one file, sirikata-x.y.z-mac.tar.gz, sitting in the top directory.

Linux

See Debian Packaging for details. As long as you've tested on Linux this package can be generated after the rest.

Source

From an existing checkout, run

   ./tools/release/build-source-release.sh x.y.z

where x.y.z is the version number you're building. One of the steps in this script is

   git checkout vx.y.z

so you need a branch or tag with that name that points at the latest commit for this release, i.e. the version number bumping commit.

This should result in one file, sirikata-x.y.z-src.zip, sitting in the top directory.

After Building Packages

• Test! Make sure the packages built on each platform are sane -- at a minimum extract them and run a space and object host.
• Upload to sirikata.com/releases/.
  • Just scp the archives into the appropriate win32/, mac/, and src/ directories on the web server.
  • Grab the Ubuntu data from launchpad's package archive after it's built and put it under ubuntu/{DISTRO}/
  • Ask Ewen for the account details.
• Upload the crash crash reporter symbols to crashes.sirikata.com.
  • Take the package sirikata-x.y.z-win32.dbg.zip generated in the build process and extract it. The directory sirikata_win32_syms/ contains Breakpad symbols that the crash collector uses to generate stacktraces. You just need to scp these to the crash server.
  • Ask Ewen for account details.
• Update the version number on the release page.
  • This is handled through a WordPress page called 'Downloads'. Edit the source of that page, just search for 'version' and update the number.
  • Again, ask Ewen for account details.
• Test the download page links. Make sure they work on each platform.