From c0bb7800289edd94e84f48186986330fa82c33cb Mon Sep 17 00:00:00 2001 From: driazati Date: Tue, 14 Mar 2023 12:11:32 -0700 Subject: [PATCH 1/2] [docs] Add details about patch releases This updates the docs with some of the discussion and methods from the v0.11.1 release issue #14260. --- docs/contribute/release_process.rst | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/docs/contribute/release_process.rst b/docs/contribute/release_process.rst index 463536f20080..ac738f2a71de 100644 --- a/docs/contribute/release_process.rst +++ b/docs/contribute/release_process.rst @@ -86,20 +86,30 @@ The last step is to update the KEYS file with your code signing key https://www. Cut a Release Candidate ----------------------- -To cut a release candidate, one needs to first cut a branch using selected version string, e.g., +To cut a release candidate, one needs to first cut a branch using selected version string. Branches should be named with the base release version without the patch. For example, to cut a candidate for ``v0.11.0``, the branch should be ``v0.11`` and a tag named ``v0.11.0.rc0`` pushed to the HEAD of that branch once cut. .. code-block:: bash git clone https://github.com/apache/tvm.git cd tvm/ - # Replace v0.6.0 with the relevant version - git branch v0.6.0 - git push --set-upstream origin v0.6.0 -(*Make sure the version numbers in the source code are correct.* Run ``python3 version.py`` to update the version.) + # Update version numbers + # ... + git add . + git commit -m"Bump version numbers to v0.6.0" + + # Replace v0.6 with the relevant version + git branch v0.6 + git push --set-upstream origin v0.6 + + git tag v0.6.0.rc0 + git push origin refs/tags/v0.6.0.rc0 + +Make sure the version numbers in the source code are correct (example: https://github.com/apache/tvm/pull/14300). Run ``python3 version.py`` to update the version. Version numbers should be updated immediately after a release candidate branch is pushed. Go to the GitHub repositories "releases" tab and click "Draft a new release", +- Verify the release by checking the version numbers and ensuring that TVM can build and run the unit tests. - Provide the release tag in the form of ``v1.0.0.rc0`` where 0 means it's the first release candidate. The tag must match this pattern ``v[0-9]+\.[0-9]+\.[0-9]+\.rc[0-9]`` exactly! - Select the commit by clicking Target: branch > Recent commits > $commit_hash - Copy and paste release note draft into the description box @@ -173,6 +183,11 @@ The release manager also needs to upload the artifacts to ASF SVN, svn ci --username $ASF_USERNAME --password "$ASF_PASSWORD" -m "Add RC" +Cherry-Picking +-------------- +After a release branch has been cut but before the release has been voted on, the release manager may cherry-pick commits from ``main``. Since release branches are protected on GitHub, to merge this fixes into the release branch (e.g. ``v0.11``), the release manager must file a PR with the cherry-picked changes against the release branch. The PR should roughly match the original one from ``main`` with extra details on why the commit is being cherry-picked. The community then goes through a normal review and merge process for these PRs. + + Call a Vote on the Release Candidate ------------------------------------ @@ -246,3 +261,7 @@ Post the Announcement --------------------- Send out an announcement email to announce@apache.org, and dev@tvm.apache.org. The announcement should include the link to release note and download page. + +Patch Releases +-------------- +Patch releases should be reserved for critical bug fixes. Patch releases must go through the same process as normal releases, with the option at the release manager's discretion of a shortened release candidate voting window of 24 hours to ensure that fixes are delivered quickly. Each patch release should bump the version numbers on the release base branch (e.g. ``v0.11``) and tags created for release candidates (e.g. ``v0.11.1.rc0``). From 751e56fae350251cf7b6cbd1e71cc3d79b36a3a7 Mon Sep 17 00:00:00 2001 From: driazati Date: Wed, 15 Mar 2023 12:46:47 -0700 Subject: [PATCH 2/2] add note about signing commits --- docs/contribute/release_process.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/contribute/release_process.rst b/docs/contribute/release_process.rst index ac738f2a71de..c59c7bb8cc11 100644 --- a/docs/contribute/release_process.rst +++ b/docs/contribute/release_process.rst @@ -185,7 +185,7 @@ The release manager also needs to upload the artifacts to ASF SVN, Cherry-Picking -------------- -After a release branch has been cut but before the release has been voted on, the release manager may cherry-pick commits from ``main``. Since release branches are protected on GitHub, to merge this fixes into the release branch (e.g. ``v0.11``), the release manager must file a PR with the cherry-picked changes against the release branch. The PR should roughly match the original one from ``main`` with extra details on why the commit is being cherry-picked. The community then goes through a normal review and merge process for these PRs. +After a release branch has been cut but before the release has been voted on, the release manager may cherry-pick commits from ``main``. Since release branches are protected on GitHub, to merge this fixes into the release branch (e.g. ``v0.11``), the release manager must file a PR with the cherry-picked changes against the release branch. The PR should roughly match the original one from ``main`` with extra details on why the commit is being cherry-picked. The community then goes through a normal review and merge process for these PRs. Note that these PRs against the release branches must be `signed `_. Call a Vote on the Release Candidate @@ -264,4 +264,4 @@ Send out an announcement email to announce@apache.org, and dev@tvm.apache.org. T Patch Releases -------------- -Patch releases should be reserved for critical bug fixes. Patch releases must go through the same process as normal releases, with the option at the release manager's discretion of a shortened release candidate voting window of 24 hours to ensure that fixes are delivered quickly. Each patch release should bump the version numbers on the release base branch (e.g. ``v0.11``) and tags created for release candidates (e.g. ``v0.11.1.rc0``). +Patch releases should be reserved for critical bug fixes. Patch releases must go through the same process as normal releases, with the option at the release manager's discretion of a shortened release candidate voting window of 24 hours to ensure that fixes are delivered quickly. Each patch release should bump the version numbers on the release base branch (e.g. ``v0.11``) and tags created for release candidates (e.g. ``v0.11.1.rc0``).