Merge pull request #26150 from ashley-cui/releaseprocess

Update RELEASE_PROCESS.md

Author: openshift-merge-bot[bot]

RELEASE_PROCESS.md

@@ -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:[email protected])
-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:[email protected]) 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:[email protected]) and [podman-desktop](mailto:[email protected]) 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.