docs: update docs for release process #193
Conversation
Signed-off-by: Shiwei Zhang <shizh@microsoft.com>
Signed-off-by: Shiwei Zhang <shizh@microsoft.com>
Signed-off-by: Shiwei Zhang <shizh@microsoft.com>
Signed-off-by: Shiwei Zhang <shizh@microsoft.com>
Signed-off-by: Shiwei Zhang <shizh@microsoft.com>
| 1. Check the new draft release, revise the release description, and publish the release. | ||
| 1. Determine a [SemVer2](https://semver.org/)-valid version prefixed with the letter `v` for release. For example, `v1.0.0-alpha.1`. | ||
| 1. Determine the commit to be tagged and released. | ||
| 1. Create an issue for voting with title similar to `vote: tag v1.0.0-alpha.1` with the proposed commit. |
There was a problem hiding this comment.
Here is a real example: notaryproject/notation-go#341
| ## Release Versioning | ||
|
|
||
| Consumers of the go-cose project may build directly from main, or pull from released builds. | ||
| Builds from main must reference the git-commit as the version: `v1.0.0-2300d5c` |
There was a problem hiding this comment.
The git-commit is not SemVer2 valid since v1.0.0-2300d5c < v1.0.0-alpha.1 < v1.0.0-b300d5c.
| - Applicable fixes, including security fixes, may be cherry-picked from main into the latest supported minor release-X.Y branches. | ||
| - Patch releases are cut from a release-X.Y.Z branch. | ||
| - Applicable fixes, including security fixes, may be cherry-picked from main into the latest supported minor `release-X.Y` branches. | ||
| - Patch releases are cut from a `release-X.Y` branch. |
There was a problem hiding this comment.
Release branch should be scoped to minor versions.
| The maintainers may periodically update this checklist based on feedback. | ||
|
|
||
| NOTE: Make sure the dependencies in `go.mod` file are expected by the release. | ||
| For example, if there are dependencies on certain version of notation library (notation-go or notation-core-go) or ORAS library (oras-go), make sure that version of library is released first, and the version number is updated accordingly in `go.mod` file. |
There was a problem hiding this comment.
This line is notation specific and does not apply to go-cose.
| > Make sure the dependencies in `go.mod` file are expected by the release. | ||
| > After updating `go.mod` file, run `go mod tidy` to ensure the `go.sum` file is also updated with any potential changes. | ||
|
|
||
| ## Release Process |
There was a problem hiding this comment.
The entire release process was for a binary release. Since go-cose is a go module (i.e. library), the release process will be largely different.
| 1. Create an issue for voting with title similar to `vote: tag v1.0.0-alpha.1` with the proposed commit. | ||
| 1. Wait for the vote pass. | ||
| 1. Cut a release branch `release-X.Y` (e.g. `release-1.0`) if it does not exist. The voted commit MUST be the head of the release branch. | ||
| - To cut a release branch directly on GitHub, navigate to `https://github.com/veraison/go-cose/tree/{commit}` and then follow the [creating a branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository#creating-a-branch-using-the-branch-dropdown) doc. |
There was a problem hiding this comment.
Glad that we can release without using command line tools. Everything can be done directly on GitHub.
OR13
left a comment
There was a problem hiding this comment.
@shizhMSFT thank you for these updates
SteveLasker
left a comment
There was a problem hiding this comment.
Thanks, @shizhMSFT
LGTM
Resolves #192