Skip to content
On this page

Making a Release

This details the release process of pioneer, written for the developer team, as the knowledge of best practice is distributed over many individuals, and memory fades with the time between each release.

(For players, we recommend those who are able, to compile the game from master, to get and try the latest features, and help report bugs.)

Pioneer is in continuous development, and technically, has never had any hardened "stable" releases. However, as of 2019, we aim to make a periodic release that bundles many new features and that has undergone a feature-freeze to find bugs, prior its release.

Due to tradition, we try to not let it be more than one year between each official release. Happenstance has made that date be February 3rd each year. (Possibly, pi-day would be better suited?)


  • In the weeks leading up the release date, finish up pull requests, merge them and then focus on ironing out bugs.
  • Announce to translators on Transifex that we have a release incoming, and give a deadline for getting new translations included. (Possibly also tweet it?). (devs with transifex-access: impaktor, robn, jpab, ecraven, sturnclaw).

Release Checklist

Things that need to be done for release

  • Ensure that transifex bot is synchronizing (ecraven), if not, run manually (impaktor, sturnclaw)

  • Ensure the Changelog, AUTHORS, README and other docs are up to date.

  • Start to draft a new release a few days in advance. Go through entire Changelog from last release, categorize new features into major and minor, and include bug fixes that are likely to have been noticeable for the player. Focus is on things relevant to the player, e.g. do not include internal code refactor changes.

  • Last merge before release:

    • bump s_saveVersion (if needed),
    • see notes in SAVEBUMP.txt on changes pending the bump
    • make sure Changelog.txt is updated, and
    • add the release text to file.
    • Update version: set(PROJECT_VERSION in top of CMakeLists.txt.
  • To publish, simply create a tag (either in the draft release, or push manually), of form YYYYMMDD. Github will start a new github action, and build windows and GNU/Linux binaries, and attach to the release notes. Note: once build is done, ensure the build artifacts have correct names: pioneer-<YYYYMMDD>-<win.exe|linux.tar.gz>.

Click for code for manual push of tag
git fetch --all -p
 git rebase upstream/master
 git tag YYYYMMDD
 # (avoid "git push --tags", as it will push all tags)
 git push upstream YYYYMMDD
  • Need to trigger re-build our home page manaully, by "Actions" tab -> "Deploy Hugo Site to pages" -> "Run workflow" drop down menu: github repo

  • Flatpack

    • Update recipe like so
    • Version tag & date
    • This link always points to latest flatpack


  • Post to SSC player community forum (impaktor, Nozmajner, & co)
  • Post to discord (Nozmajner, sturnclaw)
  • Post on Mastodon at (Nozmajner)
  • Post to Reddit (Nozmajner)
  • Post to itch (wkfo, Nozmajner, FluffyFreak, ElonSatosh)
  • Tweet it (impaktor)
  • Make a Youtube community post / or even a trailer video?

Monitor downloads

Code for seeing downloads
`curl -s | egrep '"name"|"download_count"'`
  • Itch tracs its own downloads
  • Flathub shows cumulative downloads
  • (Sourceforge has public download stats)


Old/obsolete practices currently not in use / maintained