Update release steps and process

Signed-off-by: steve lasker <[email protected]>

release-checklist.md

@@ -4,20 +4,36 @@
 
 This document describes the checklist to publish a release via GitHub workflow.
 
-The maintainers may periodically update this checklist based on feedback.
+See [Release Management](./release-management.md) for the overall process of versioning and support.
 
 > [!NOTE]
-> 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.
+The maintainers may periodically update this checklist based on feedback.
+
+## Release Steps
 
-## Release Process
+Releasing is a two-step process for voting on a specific release, and cutting 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`.
+### Vote On a Specific Commit
+
+1. Determine a [SemVer2](https://semver.org/)-valid version prefixed with the letter `v` for release. For example, `v1.0.0-alpha.1`, `v1.0.0`.
+1. Make sure the dependencies in `go.mod` file are expected by the release.
+1. After updating `go.mod` file, run `go mod tidy` to ensure the `go.sum` file is also updated with any potential changes.
 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.
-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.
-1. Draft a new release from the release branch by following the [creating a release](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release) doc. Set release title to the voted version and create a tag in the **Choose a tag** dropdown menu with the voted version as the tag name.
-1. Proofread the draft release, and publish the release.
+1. Create an issue for voting with title similar to **"vote**: `tag v1.0.0-alpha.1` with the proposed commit. (see [Issue #204](https://github.com/veraison/go-cose/issues/204)
+1. Request a 👍or 👎from each maintainer, requesting details if they voted against, and opening a corresponding issue.
+1. Wait a max of 2 weeks for the vote pass, or sooner if a majority of maintainers approve.
+
+### Cut a Release
+
+1. Select [[Draft a new release](https://github.com/veraison/go-cose/releases/new)]
+1. **[Choose a tag]**: Create a new tag based on Alpha, RC or a final release: (`v1.0.0-alpha.1`, `v1.0.0-rc.1`, `v1.0.0`).
+1. **[Target]**: Select the voted commit in "Recent Commits".
+1. **[Previous Tag]**: Select the previous corresponding release.
+   1. For alpha and rc releases, select the previous release within that release band (rc.1, select the latest alpha release).
+   1. For final releases, select the previous full release: ([v1.3.0](https://github.com/veraison/go-cose/releases/tag/v1.3.0), selects [v1.1.0](https://github.com/veraison/go-cose/releases/tag/v1.1.0))
+1. **[Generate Release Notes]**: Edit for spelling and clarity.
+1. **[Release title]** Set to the same value as the tag and voted issue.
+1. **[Set as a pre-release]**: Set if the release is an alpha or rc.  
+   Do not set for final release.
+1. **[Set as the latest release]**: To bring focus to the latest, always check this box.
 1. Announce the release in the community.

release-management.md

@@ -8,8 +8,10 @@ The go-cose project maintainers strive to provide a stable go-lang implementatio
 Stable implies appropriate and measured changes to the library assuring consumers have the necessary functionality to interact with COSE objects.
 If you or your project require added functionality, or bug fixes, please open an issue or create a pull request.
 The project welcomes all contributions from adding functionality, implementing testing, security reviews to the release management.
-Please see [here](https://github.com/veraison#contributing) for how to contribute.
 
+To cut a release, see [Release Checklist](./release-checklist.md).
+
+> [!NOTE]
 The maintainers may periodically update this policy based on feedback.
 
 ## Release Versioning
@@ -33,16 +35,10 @@ A new major or minor release will not have an automated release posted until the
 The suffix will be a single digit.
   - If > 9 builds do occur, the format will simply use two digit indicators (`v1.0.0-alpha.10`)
 
-> [!IMPORTANT]
-> Pre-releases will NOT use the github pre-release flag.
-
 ## Branch Management
 
-To meet the projects stability goals, go-cose does not currently operate with multiple feature branches.
-All active development happens in `main`.
-For each release, a branch is created for servicing, following the versioning name.
-`v1.0.0-alpha-1` would have an associated [v1.0.0-alpha.1](https://github.com/veraison/go-cose/tree/v1.0.0-alpha.1) branch.
-All version and branch names are lower case.
+To meet the projects stability goals, go-cose does not typically operate with multiple feature branches.
+All active development happens in `main`, with releases made on a specific commit.
 
 ### Major Releases
 
@@ -77,8 +73,8 @@ Principals of a patch release:
 - No breaking changes.
 - No feature or surface area changes.
 - A "bug fix" that may be a breaking change may require a major release.
-- 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.
+- If a patched release is necessary, deviating from main, a new branch will be created, based on the commit of the patched release.
+- Applicable fixes, including security fixes, may be cherry-picked from main into the patched `release-X.Y.Z` branch.
 
 Each patch release will go through one or more `-alpha.n` and `-rc.n` pre-release phases.