Release process

This happens every Sunday.

  1. Push a commit containing [rebuild] [release] in the commit message.
  2. Wait for the build to complete at
  3. Manually download the 3 .zip files
  4. With your current directory set to where the .zips are downloaded, run ~/abstreet/release/ v0_2_38, changing the version number. (That path assumes the abstreet git repo is in your home directory.)
  5. If you want, sanity check that the final generated binaries work. Sometimes I test things like the map importer or that maps not included by default can be downloaded.
  6. Create a new release at Make sure the version matches, with a different format -- v0.2.38. The description should match what later goes in the changelog, and the name really ought to be gastronomically offensive.
  7. Upload the 3 transformed .zips created by -- they're named something like
  8. Publish release!
  9. From the root directory of the abstreet repo, run ./release/ 37 38. When the major version number changes, update that script first. This updates the latest release from 0.2.37 to 0.2.38. It assumes the repo is in your home directory named ~/docs.
  10. Go fill out ~/docs/book/src/project/history/; the notes should match what's in the Github release.
  11. Follow the steps that the script tells you. Don't forget to push the commit on the main abstreet repo as well.

One of the steps is an S3 copy. This "freezes" the current "dev" data and web deployment as a named version. The URL would be something like

How it works

The process is kind of convoluted; help is always welcome to smooth it out.

Github Actions is used to build for all 3 platforms. .github/workflows/main.yml is configured to only build when [rebuild] is in the commit message. [release] enables a cargo feature flag that tells map_gui/src/tools/ where to look to download new system data. Because the binary map format changes, an older release has to be pinned to a particular versioned copy of all the system data. The workflow calls release/, which assembles the directory structure with all of the executables, system data (obtained by running the updater with the default Seattle-only opt-in), and instructions.

There's some funkiness with producing a .zip, because uploading Github artifacts always double-zips, and also on the Windows runner, there doesn't seem to be a way to create a .zip. That's why the extra step of downloading the build artifacts and running release/ locally is necessary.