Making a release

Note

These instructions are intended for the Cute Chess developers for creating a release. If you want to build Cute Chess from source, see Building from source

1. Make sure that all features and bug fixes intended for the next release are merged to the master branch.
2. Update the release notes (CHANGELOG.md). Follow the convention from previous releases. Remember to change the "Unreleased" heading to match the next release. Typically, "Unreleased" is kept as-is during any pre-release version (such as beta).
3. Run the release tool located in the root directory of the repository with only 1 parameter, the next release number. For example, ./release-tool 2.0.0. Follow SemVer and don't prefix the version number with "v".
   If it's a pre-release, run the release tool for each beta release with increasing the beta release number, ./release-tool 2.0.0-beta1, ./release-tool 2.0.0-beta2 and so on. Once you're happy with with the release, run the release tool once more for the final release, i.e. ./release-tool 2.0.0.
4. The release tool will check common mistakes when making release, such as releasing accidentally from a feature branch and having unstaged changes. Fix any errors reported.
5. Release tool will tag the release and open up the editor for tag annotation. These can be left as-is, or release notes can be added to the tag. Save and close the editor.
6. Next, you need to push the tags to GitHub: git push origin master --follow-tags. GitHub CI will pick up the pushed tags and start automatically building the binaries for the release.
7. Go to the GitHub Releases page, https://github.com/cutechess/cutechess/releases, and edit the last release. It should have the version you gave to release-tool and be in "Draft" state, i.e. invisible to public.
8. Update the release notes for the release by for example copying them from the CHANGELOG.md. For pre-releases the release notes are typically omitted. If unsure, follow the convention of previous releases.
9. There are two checkboxes at the bottom which control the release type: pre-release or latest (stable) release. Select the correct one and publish the release.
10. GitHub CI will build the binaries and attach them automatically to the release. The state of the release ("Draft" or something else) doesn't matter.