opensource/podman
1
0
Fork 0
mirror of https://github.com/containers/podman.git synced 2025-10-15 10:16:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update RELEASE_PROCESS.md

Browse Source 
We've added a bunch of new automation to make releases easier. Update RELEASE_PROCESS.md to reflect the changes.

Signed-off-by: Ashley Cui <acui@redhat.com>
This commit is contained in:
Ashley Cui
2025-05-16 14:58:45 -04:00
parent 3bf3d869b6
commit b9cc2d87d7
1 changed files with 52 additions and 103 deletions
Download Patch File Download Diff File Expand all files Collapse all files

155
RELEASE_PROCESS.md
View File

@ -12,10 +12,10 @@ development efforts occur on the *main* branch. Branches with a
## Release workflow expectations
* You have push access to the [upstream podman repository](https://github.com/containers/podman.git)
* You have push access to the [upstream podman repository](https://github.com/containers/podman.git), and the upstream [podman-machine-os repository](https://github.com/containers/podman-machine-os)
* You understand all basic `git` operations and concepts, like creating commits,
local vs. remote branches, rebasing, and conflict resolution.
* You have access to your public and private *GPG* keys.
* You have access to your public and private *GPG* keys. They should also be documented on our [release keys repo](https://github.com/containers/release-keys).
* You have reliable internet access (i.e. not the public WiFi link at McDonalds)
* Other podman maintainers are online/available for assistance if needed.
* For a **major** release, you have 4-8 hours of time available, most of which will
@ -25,12 +25,11 @@ development efforts occur on the *main* branch. Branches with a
* You will announce the release on the proper platforms
(i.e. Podman blog, Twitter, Mastodon Podman and Podman-Desktop mailing lists)
# Prechecks
# Release cadence
Two days before actually cutting a release (including RCs), send an announcement to the
[podman-desktop](mailto:podman-desktop@lists.podman.io)
mailing list about the upcoming release. This will help the Podman Desktop team test and schedule
their own new release.
Upstream major or minor releases occur the 2nd week of February, May, August, November.
Branching and RC's may start several weeks beforehand.
Patch releases occur as-needed.
# Releases
@ -66,9 +65,8 @@ spelled with complete minutiae.
1. Create a new upstream release branch (if none already exist).
1. Check if a release branch is needed. Typically, major and minor version bumps
should be branched sometime during the release candidate phase. Patch
releases typically already have a branch created.
1. Check if a release branch is needed. All major and minor releases should be branched before RC1.
Patch releases typically already have a branch created.
Branching ensures all changes are curated before inclusion in the
release, and no new features land after the *release-candidate* phases
are complete.
@ -78,13 +76,11 @@ spelled with complete minutiae.
`git checkout -b vX.Y`. Where `X.Y` represent the complete release
version-name, including any suffix (if any) like `-rhel`. ***DO NOT***
include any `-rc` suffix in the branch name.
1. Edit the `.cirrus.yml` file, changing the `DEST_BRANCH` value (under the
`env` section) to the new, complete branch name (e.x. `vX.Y`).
Commit and sign, using the description
`Cirrus: Update operating branch`.
1. Push the new branch otherwise unmodified (`git push upstream vX.Y`).
1. Automation will begin executing on the branch immediately. Because
the repository allows out-of-sequence PR merging, it is possible that
1. Check if a release branch is needed on the `podman-machine-os` repo.
If so, repeat above steps for `podman-machine-os`.
1. Back on the podman repo, automation will begin executing on the branch immediately.
Because the repository allows out-of-sequence PR merging, it is possible that
merge order introduced bugs/defects. To establish a clean
baseline, observe the initial CI run on the branch for any unexpected
failures. This can be done by going directly to
@ -153,12 +149,7 @@ spelled with complete minutiae.
1. Commit the `RELEASE_NOTES.md` changes, using the description
`Create release notes for vX.Y.Z` (where `X`, `Y`, and `Z` are the
actual version numbers).
1. Open a Release Notes PR, or include this commit with the version bump PR
* If you decide to open a PR with just release notes, make sure that
the commit has the prefix `[CI:DOCS]` to avoid triggering
lengthy automated testing.
* Otherwise, the release notes commit can also be included in the
following release PR.
1. Open a Release Notes PR, or include this commit with the version bump PR.
1. Update version numbers and push tag
@ -177,29 +168,53 @@ spelled with complete minutiae.
task `Optional Release Test`. In the right-hand window pane, click
the `trigger` button and wait for the test to go green. *This is a
critical step* which confirms the commit is worthy of becoming a release.
1. In the PR, under the *Checks* tab, a GitHub actions [task](https://github.com/containers/podman/actions/workflows/machine-os-pr.yml) will run.
This action opens a PR on the [podman-machine-os repo](https://github.com/containers/podman-machine-os), which builds VM images for the release. The action will also link the `podman-machine-os` pr in a comment on the podman PR
This action also automatically applies the `do-not-merge/wait-machine-image-build` to the Podman PR, which blocks merging until VM images are built and published.
1. Go to the `podman-machine-os` bump pr, by clicking the link in the comment, or by finding it in the [podman-machine-os repo](https://github.com/containers/podman-machine-os/pulls).
1. Wait for automation to finish running
1. Once you are sure that there will be no more force pushes on the Podman release PR, merge the `podman-machine-os` bump PR
1. Tag the `podman-machine-os` bump commit with the same version as the podman release. (git tag -s -m 'vX.Y.Z' vX.Y.Z)
1. Push the tag.
1. The tag will automatically trigger a Cirrus task, named “Publish Image”,
to publish the release images. It will push the images to Quay and cut a release on the `podman-machine-os` repo. Wait for this task to complete. You can monitor the task on the [Cirrus CI dashboard](https://cirrus-ci.com/github/containers/podman-machine-os)
1. Return to the Podman repo
1. The `do-not-merge/wait-podman-machine-os` label should be automatically
un-set once the `podman-machine-os` release is finished.
1. Wait for all other PR checks to pass.
1. Wait for other maintainers to merge the PR.
1. Tag the `Bump to vX.Y.Z` commit as a release by running
`git tag -s -m 'vX.Y.Z' vX.Y.Z $HASH` where `$HASH` is specified explicitly
and carefully, to avoid (basically) unfixable accidents (if they are pushed).
1. Change `version/rawversion/version.go` again. This time, bump the **patch** version and
re-add the `-dev` suffix to indicate this is a non-released version of Podman.
1. Change `contrib/spec/podman.spec.in`, bumping **patch** number of `Version`.
1. Commit these changes with the message `Bump to X.Y.Z-dev`.
1. Push your local branch to your GitHub fork (and the PR) again.
1. The PR should now have two commits that look very similar to
https://github.com/containers/podman/pull/7787
Note: Backports and release note commits may also be included in the release PR.
1. Wait for at least all the "Build" and "Verify" (or similar) CI Testing
steps to complete successfully. No need to wait for complete integration
4and system-testing (it was already done on substantially the same code, above).
1. Merge the PR (or ask someone else to review and merge, to be safer).
`git tag -s -m 'vX.Y.Z' vX.Y.Z $HASH` where `$HASH` is specified explicitly and carefully, to avoid (basically) unfixable accidents
(if they are pushed).
1. **Note:** This is the last point where any test-failures can be addressed
by code changes. After pushing the new version-tag upstream, no further
changes can be made to the code without lots of unpleasant efforts. Please
seek assistance if needed, before proceeding.
1. Assuming the "Bump to ..." PR merged successfully, and you're **really**
confident the correct commit has been tagged, push it with
`git push upstream vX.Y.Z`
1. Monitor release automation
1. After the tag is pushed, the release GitHub action should run.
This action creates the GitHub release from the pushed tag,
and automatically builds and uploads the binaries and installers to the release.
1. The following artifacts should be attached to the release:
* podman-installer-macos-amd64.pkg
* podman-installer-macos-arm64.pkg
* podman-installer-macos-universal.pkg
* podman-installer-windows-amd64.exe
* podman-installer-windows-arm64.exe
* podman-remote-release-darwin_amd64.zip
* podman-remote-release-darwin_arm64.zip
* podman-remote-release-windows_amd64.zip
* podman-remote-release-windows_arm64.zip
* podman-remote-static-linux_amd64.tar.gz
* podman-remote-static-linux_arm64.tar.gz
* shasums
1. An email should have been sent to the [podman](mailto:podman@lists.podman.io) mailing list.
Keep an eye on it make sure the email went through to the list.
1. After the release action is run, an action to bump the Podman version on podman.io will run. This action will open a PR if a non-rc latest version is released. Go to the podman.io repo and merge the PR opened by this action, if needed.
1. After the tag is pushed, an action to bump to -dev will run. A PR will be opened for this bump. Merge this PR if needed.
1. Locate, Verify release testing is proceeding
@ -220,68 +235,6 @@ spelled with complete minutiae.
"View All Tasks".
1. Keep this page open to monitor its progress and for use in future steps.
1. Bump main `-dev` version
1. If you made a release branch and bumped **major** or **minor** version
Complete the "Update version numbers and push tag" steps above on the
*main* branch. Bump the **minor** version and set the **patch**
version to 0. For example, after pushing the v2.2.0 release, *main*
should be set to v2.3.0-dev.
1. Create a "Bump to vX.Y.Z-dev" commit with these changes.
1. Update `RELEASE_NOTES.md` on main. Commit these changes.
1. Create a PR with the above commits, and oversee it's merging.
1. Create GitHub Release entry and upload assets
1. Return to the Cirrus-CI Build page for the new release tag, confirm
(or wait for) it to complete, re-running any failed tasks as appropriate.
1. Go to `https://github.com/containers/podman/releases/tag/vX.Y.Z` and
press the "Edit Release" button. Change the name to the form `vX.Y.Z`
1. If this is a release candidate be certain to click the pre-release
checkbox at the bottom of the page.
1. If this new release will be the latest version released, be certain to
click the latest release checkbox at the bottom of the page.
1. Copy and paste the release notes for the release into the body of
the release.
1. Click the Publish button to make the release (or pre-release)
available.
1. For all releases, including RC's, artifacts should be published. The
release-artifacts, upload-win-installer, and mac-pkg GitHub Actions
should automatically take care of building, signing, and uploading artifacts.
Check the "Actions" tab, after publishing you should see the jobs running.
There may be more than one running due to the multiple
event states triggered, but this can be ignored, as any duplicates
will gracefully back-off. The job takes 5-6 minutes to complete.
Please note that the Windows action depends on the artifact action, and will be
triggered after the artifact action succeeds.
If any of these actions are somehow not triggered, you can manually trigger them
### *CLI Approach*
1. Install the [GitHub CLI](https://github.com/cli/cli#installation)
1. Run (replacing below version number to release version)
```
gh workflow run "ACTION NAME" -F version="vX.Y.Z"
```
### *GUI Approach*
1. Go to the "Actions" tab
1. On the left pick the required action to be triggered.
1. A blue box will appear above the job list with a right side drop
-down. Click the drop-down and specify the version number in the
dialog that appears
1. Check that all following artifacts are now attached to the release
* podman-remote-release-darwin_amd64.zip
* podman-remote-release-darwin_arm64.zip
* podman-remote-release-windows_amd64.zip
* podman-vX.Y.Z.msi
* podman-remote-static-linux_amd64.tar.gz
* podman-remote-static-linux_arm64.tar.gz
* podman-installer-macos-amd64.pkg
* podman-installer-macos-arm64.pkg
* podman-5.2.1-setup.exe
* shasums
1. Update Cirrus-CI cron job list
1. After any Major or significant minor (esp. `-rhel`) releases, it's critical to
maintain the Cirrus-CI cron job list. This applies to all containers-org repos,
@ -310,9 +263,5 @@ spelled with complete minutiae.
Highlight key features and important changes or fixes. Link to the GitHub release.
Make sure the blog post is properly tagged with the Announcement, Release, and Podman tags,
and any other appropriate tags.
1. For all releases, including patch releases and RC's, send an email to the [podman](mailto:podman@lists.podman.io) and [podman-desktop](mailto:podman-desktop@lists.podman.io) mailing lists. This should be automated by the release-artifacts
action, but it's best to keep and eye on it to see if the email went through to the lists.
Link the to release blog and GitHub release.
1. Update [LATEST_VERSION](https://github.com/containers/podman.io/blob/main/static/data/global.ts) on the Podman.io website.
1. Tweet the release. Make a Mastodon post about the release.
1. RC's can also be announced if needed.