mirror of
https://github.com/helix-editor/helix
synced 2024-11-10 10:34:45 +01:00
Update release docs (#11182)
These haven't been updated in a little while. The original plan was to update the version (in `Cargo.toml`) after a release to the next planned release date but the way we release now is to update the version as a part of the release process (just before tagging). Typically this is all taken care of in the CHANGELOG-updating branch along with the other documentation changes like the appdata file. The workflow now is basically just to merge the changelog/release branch, pull, tag and push.
This commit is contained in:
parent
aac81424cd
commit
22a051408a
@ -5,19 +5,18 @@ Helix releases are versioned in the Calendar Versioning scheme:
|
|||||||
`22.05.1`. In these instructions we'll use `<tag>` as a placeholder for the tag
|
`22.05.1`. In these instructions we'll use `<tag>` as a placeholder for the tag
|
||||||
being published.
|
being published.
|
||||||
|
|
||||||
* Merge the changelog PR
|
* Merge the PR with the release updates. That branch should:
|
||||||
* 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)
|
* Update the version:
|
||||||
|
* Update the `workspace.package.version` key in `Cargo.toml`. Cargo only accepts
|
||||||
|
SemVer versions so a CalVer version of `22.07` for example must be formatted
|
||||||
|
as `22.7.0`. Patch/bugfix releases should increment the SemVer patch number. A
|
||||||
|
patch release for 22.07 would be `22.7.1`.
|
||||||
|
* Run `cargo check` and commit the resulting change to `Cargo.lock`
|
||||||
|
* Add changelog notes to `CHANGELOG.md`
|
||||||
|
* 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)
|
||||||
* Tag and push
|
* Tag and push
|
||||||
* `git tag -s -m "<tag>" -a <tag> && git push`
|
* Switch to master and pull
|
||||||
* Make sure to switch to master and pull first
|
* `git tag -s -m "<tag>" -a <tag> && git push` (note the `-s` which signs the tag)
|
||||||
* Edit the `Cargo.toml` file and change the date in the `version` field to the next planned release
|
|
||||||
* Due to Cargo having a strict requirement on SemVer with 3 or more version
|
|
||||||
numbers, a `0` is required in the micro version; however, unless we are
|
|
||||||
publishing a patch release after a major release, the `.0` is dropped in
|
|
||||||
the user facing version.
|
|
||||||
* Releases are planned to happen every two months, so `22.05.0` would change to `22.07.0`
|
|
||||||
* If we are pushing a patch/bugfix release in the same month as the previous
|
|
||||||
release, bump the micro version, e.g. `22.07.0` to `22.07.1`
|
|
||||||
* Wait for the Release CI to finish
|
* Wait for the Release CI to finish
|
||||||
* It will automatically turn the git tag into a GitHub release when it uploads artifacts
|
* It will automatically turn the git tag into a GitHub release when it uploads artifacts
|
||||||
* Edit the new release
|
* Edit the new release
|
||||||
|
Loading…
Reference in New Issue
Block a user