Making a release

How a new version of Tesria is made. Versions are numbered like 0.6.0: the last number changes for fixes, the middle one for new features, and the first will become 1 when Tesria promises to stay compatible.

Step 1: Make sure everything passes

The tests, scripts/audit.sh, and a look at the app in a browser.

Step 2: Write the release down

In docs/CHANGELOG.md, rename the [Unreleased] section to the new version and today’s date, with a short list of highlights at its top, and start a new empty [Unreleased]. Add the version’s page under Release notes, for readers of this site.

Step 3: Tag it

git tag -a v0.6.0 -m "Tesria 0.6.0"
git push origin v0.6.0

The tag starts the release on GitHub: the tests run again, the app’s image is built with the tag’s version stamped into it, and a GitHub release is published with the changelog’s section for it.

Step 4: Attach the docs

Once the release is published, export the docs and attach them to it, so the release carries the docs for that version as a wiki pack and as a website:

scripts/docs/export-docs.sh
scripts/docs/release-docs.sh v0.6.0

Between releases, scripts/docs/release-docs.sh with no version updates the standing docs release instead, which always holds the latest export. The exports are never committed.

Step 5: Start the next version

Set the next version, with -dev, in src/Api/Api.csproj and src/web/package.json, so a build between releases can never be mistaken for one.