feedc0de/my-rook-config
1
0 Fork 0
forked from rook/rook
Code Pull Requests Activity

Merge pull request #11560 from koor-tech/feature/ksd-138

Browse Source
This commit is contained in:
Alexander Trost authored and GitHub committed 2023-01-19 23:58:58 +01:00
2 parents 00697402cb b12569c423
commit 7c8cb46857
1 file changed
+39 -9
Download Patch File Download Diff File Expand all files Collapse all files
build/release/README.md
+39 -9
View File
@@ -8,8 +8,6 @@ The workflow at a high level for minor releases is as follows:
2. Create the new release branch with a beta release when the commits are winding down
3. When all the release criteria is met we tag the final release
GitHub actions provide all the jobs to complete the release -- there is no need to perform any of the release tasks on a build/dev machine.
## Minor Release Criteria
Before the process of releasing a new version of Rook can begin, all items in the below release criteria must be completed and verified.
@@ -19,11 +17,11 @@ The maintainers have the responsibility of ensuring this criteria is met.
* All blocking issues in the github project are in the "Done" column, with the exception of issues we are planning to include in an upcoming patch release.
* Pending release notes have been authored and cover all notable features and changes in the release.
* Automated Testing
* Latest build from master is Green with unit tests and integration tests succeeding for the full test matrix.
* Latest build from `master` is Green with unit tests and integration tests succeeding for the full test matrix.
* Upgrade
* The upgrade guide is fully walked through with all optional components from the previous **official release** to the release candidate in master.
* The upgrade guide is fully walked through with all optional components from the previous **official release** to the release candidate in `master`.
* Sign-off
* Maintainers have signed-off (approved) of the release in accordance with the [project governance voting policy](/GOVERNANCE.md#conflict-resolution-and-voting). If a maintainer is unavailable, advance approval is okay. Approval can be verbal or written.
* Maintainers have signed-off (approved) of the release in accordance with the [project governance voting policy](/GOVERNANCE.md#conflict-resolution-and-voting). If a maintainer is unavailable, advance approval is okay. Approval can be verbal or written.
## Release Process
@@ -40,7 +38,7 @@ The release tags should be agreed on by the release team.
### Creating the Release Branch
The first time a minor release tag is pushed, the release branch will be created from master.
The first time a minor release tag is pushed, the release branch will be created from `master`.
Push an alpha version tag the first time the branch is created (e.g. `v1.8.0-alpha.0`).
Tagging will cause the release branch to be created. Next, merge a PR to the new release branch
@@ -53,15 +51,47 @@ in the next section with the updated version.
**IMPORTANT** Before tagging the release, open a new PR to update the documentation and example manifest tags to the release version.
To publish a new release build, run the `Tag` action in GitHub actions. Be sure to use the correct branch for the
release. New minor releases will always be run from master, and patch releases will come from a
previously created release branch.
To publish a new patch release build, follow these steps:
1. Make sure all needed PRs are merged to the release branch
2. Check that integration tests are green (except intermittent issues)
3. Open a PR to update the version, and merge it
4. Tag the branch:
```console
# make sure no files are checked out locally, then proceed:
git checkout <branch> # e.g. release-1.10
git pull
# set to the new release
tag_name=<release version> # e.g., v1.10.9
git tag -a "$tag_name" -m "$tag_name release tag"
git push upstream "$tag_name"
```
5. Generate release notes:
```console
git checkout master
git fetch -A
export FROM_BRANCH=<release version> # e.g., v1.10.9
export TO_TAG=<previous release version> # e.g., v1.10.8
tests/scripts/gen_release_notes.sh
```
6. When the release build is done (~15 minutes after tagging and pushing), publish the release notes by [creating the release on GitHub](https://github.com/rook/rook/releases).
Be sure to review the [Authoring Release Notes section below](#authoring-release-notes).
### After a Minor Release
1. Go to [Google Search Console](https://search.google.com/search-console/) and request removal of the previous minor release's versioned documentation paths.
### Authoring Release Notes
Every official release should have comprehensive and well written release notes published.
While work is ongoing for a milestone, contributors should be keeping the [pending release notes](/PendingReleaseNotes.md) up to date, so that should be used as a starting point.
A script [`tests/scripts/gen_release_notes.sh`](/tests/scripts/gen_release_notes.sh) is used to generate the release notes automatically.
The release notes should be authored to communicate as clearly as possible the features and bug
fixes that would possibly affect end users. Small fixes to the CI, docs, or other non-product
issues need not be mentioned.