Release process

All builds are created in the CI pipeline, but there is some manual work that needs to be done for their release. Here you can find short checklists of the things that should be done - please go through all of the points before you start executing the first one.

Preparing the release

• Bump the version number in the package.json - e.g., from 0.4.0-dev to 0.5.0-dev - but do not push it yet!
• Draft a new release with tag vX where X is the version that was used in the package.json, e.g., v0.5.0-dev.
• Feel free to commit and push the package.json. All commits will get their distributable files built and uploaded to Github.

Releasing a production release

The prepared release does not have to be released to the public. If it makes sense, as it makes for internal releases, you can just as well skip that and start preparing a new one. Just make sure not to publish the release - that it stays as a draft. These steps should be followed if you want it to be released to the public.

• Distributable files in the release on the Github will not be signed properly by default. To create signed distributable files, run the CI pipeline manually in the Azure Pipelines with a custom user variable sign set to true.
• After the build ended successfully, make sure all of the attached files are there and test them manually on each platform.
• Check the draft release has a correct title and description describing all features or fixes.
• Publish the release in the Github. It'll be available to auto-update from now on. To also make it available on the website, bump the version number in the release.json.