@@ -1,16 +1,23 @@
1## Checklist
1## Checklist
3Helix releases are versioned in the Calendar Versioning scheme:
3Helix releases are versioned in the Calendar Versioning scheme:
4−`YY.0M(.MICRO)`, for example, `22.05` for May of 2022. In these instructions
4+`YY.0M(.MICRO)`, for example, `22.05` for May of 2022, or in a patch release,
5−we'll use `<tag>` as a placeholder for the tag being published.
5+`22.05.1`. In these instructions we'll use `<tag>` as a placeholder for the tag
7* Merge the changelog PR
8* Merge the changelog PR
8* Add new `<release>` entry in `contrib/Helix.appdata.xml` with release information according to the [AppStream spec](https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Releases.html)
9* Add new `<release>` entry in `contrib/Helix.appdata.xml` with release information according to the [AppStream spec](https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Releases.html)
9* Tag and push
10* Tag and push
10 * `git tag -s -m "<tag>" -a <tag> && git push`
11 * `git tag -s -m "<tag>" -a <tag> && git push`
11 * Make sure to switch to master and pull first
12 * Make sure to switch to master and pull first
12−* Edit the `VERSION` file and change the date to the next planned release
13+* Edit the `Cargo.toml` file and change the date in the `version` field to the next planned release
14+ * Due to Cargo having a strict requirement on SemVer with 3 or more version
15+ numbers, a `0` is required in the micro version; however, unless we are
16+ publishing a patch release after a major release, the `.0` is dropped in
17+ the user facing version.
13− * Releases are planned to happen every two months, so `22.05` would change to `22.07`
18+ * Releases are planned to happen every two months, so `22.05.0` would change to `22.07.0`
19+ * If we are pushing a patch/bugfix release in the same month as the previous
20+ release, bump the micro version, e.g. `22.07.0` to `22.07.1`
14* Wait for the Release CI to finish
21* Wait for the Release CI to finish
15 * It will automatically turn the git tag into a GitHub release when it uploads artifacts
22 * It will automatically turn the git tag into a GitHub release when it uploads artifacts
16* Edit the new release
23* Edit the new release
@@ -57,4 +64,4 @@ versions for convenience:
57> release. For the full log, check out the git log.
64> release. For the full log, check out the git log.
59Typically, small changes like dependencies or documentation updates, refactors,
66Typically, small changes like dependencies or documentation updates, refactors,
60−or meta changes like GitHub Actions work are left out.
67+or meta changes like GitHub Actions work are left out.