[llvm] 6f798e4 - HowToReleaseLLVM: Clean up document and remove references to SVN
Tom Stellard via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 22 11:35:38 PDT 2020
Author: Tom Stellard
Date: 2020-10-22T11:34:03-07:00
New Revision: 6f798e460ca3ddecb207b563d157d5ae3163cd55
URL: https://github.com/llvm/llvm-project/commit/6f798e460ca3ddecb207b563d157d5ae3163cd55
DIFF: https://github.com/llvm/llvm-project/commit/6f798e460ca3ddecb207b563d157d5ae3163cd55.diff
LOG: HowToReleaseLLVM: Clean up document and remove references to SVN
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D80395
Added:
Modified:
llvm/docs/HowToReleaseLLVM.rst
Removed:
################################################################################
diff --git a/llvm/docs/HowToReleaseLLVM.rst b/llvm/docs/HowToReleaseLLVM.rst
index e85faf7eadf1..b0308a184194 100644
--- a/llvm/docs/HowToReleaseLLVM.rst
+++ b/llvm/docs/HowToReleaseLLVM.rst
@@ -66,51 +66,46 @@ Release Administrative Tasks
This section describes a few administrative tasks that need to be done for the
release process to begin. Specifically, it involves:
-* Creating the release branch,
+* Updating version numbers,
-* Setting version numbers, and
+* Creating the release branch, and
* Tagging release candidates for the release team to begin testing.
Create Release Branch
^^^^^^^^^^^^^^^^^^^^^
-Branch the Subversion trunk using the following procedure:
+Branch the Git trunk using the following procedure:
#. Remind developers that the release branching is imminent and to refrain from
committing patches that might break the build. E.g., new features, large
patches for works in progress, an overhaul of the type system, an exciting
new TableGen feature, etc.
-#. Verify that the current Subversion trunk is in decent shape by
+#. Verify that the current git trunk is in decent shape by
examining nightly tester and buildbot results.
-#. Create the release branch for ``llvm``, ``clang``, and other sub-projects,
- from the last known good revision. The branch's name is
- ``release_XY``, where ``X`` is the major and ``Y`` the minor release
- numbers. Use ``utils/release/tag.sh`` to tag the release.
+#. Bump the version in trunk to N.0.0git and tag the commit with llvmorg-N-init.
+ If ``X`` is the version to be released, then ``N`` is ``X + 1``.
-#. Advise developers that they may now check their patches into the Subversion
- tree again.
-
-#. The Release Manager should switch to the release branch, because all changes
- to the release will now be done in the branch. The easiest way to do this is
- to grab a working copy using the following commands:
+::
- ::
+ $ git tag -a llvmorg-N-init
- $ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XY llvm-X.Y
+#. Clear the release notes in trunk.
- $ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XY clang-X.Y
+#. Create the release branch from the last known good revision from before the
+ version bump. The branch's name is release/X.x where ``X`` is the major version
+ number and ``x`` is just the letter ``x``.
- $ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XY test-suite-X.Y
+#. All tags and branches need to be created in both the llvm/llvm-project and
+ llvm/llvm-test-suite repos.
Update LLVM Version
^^^^^^^^^^^^^^^^^^^
After creating the LLVM release branch, update the release branches'
-``CMakeLists.txt`` versions from '``X.Ysvn``' to '``X.Y``'.
-Update it on mainline as well to be the next version ('``X.Y+1svn``').
+``CMakeLists.txt`` versions from '``X.0.0git``' to '``X.0.0``'.
In addition, the version numbers of all the Bugzilla components must be updated
for the next release.
@@ -118,26 +113,33 @@ for the next release.
Tagging the LLVM Release Candidates
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Tag release candidates using the tag.sh script in utils/release.
+Tag release candidates:
::
- $ ./tag.sh -release X.Y.Z -rc $RC
+ $ git tag -a llvmorg-X.Y.Z-rcN
The Release Manager may supply pre-packaged source tarballs for users. This can
be done with the export.sh script in utils/release.
+Tarballs, release binaries, or any other release artifacts must be uploaded to
+GitHub. This can be done using the github-upload-release.py script in utils/release.
+
+::
+
+ $ github-upload-release.py upload --token <github-token> --release X.Y.Z-rcN --files <release_files>
+
::
$ ./export.sh -release X.Y.Z -rc $RC
This will generate source tarballs for each LLVM project being validated, which
-can be uploaded to the website for further testing.
+can be uploaded to github for further testing.
-Build Clang Binary Distribution
+Build The Binary Distribution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-Creating the ``clang`` binary distribution requires following the instructions
+Creating the binary distribution requires following the instructions
:doc:`here <ReleaseProcess>`.
That process will perform both Release+Asserts and Release builds but only
@@ -301,20 +303,12 @@ Below are the rules regarding patching the release branch:
Merging Patches
^^^^^^^^^^^^^^^
-The ``utils/release/merge.sh`` script can be used to merge individual revisions
-into any one of the llvm projects. To merge revision ``$N`` into project
-``$PROJ``, do:
+Use the ``git cherry-pick -x`` command to merge patches to the release branch:
-#. ``svn co https://llvm.org/svn/llvm-project/$PROJ/branches/release_XX
- $PROJ.src``
-
-#. ``$PROJ.src/utils/release/merge.sh --proj $PROJ --rev $N``
+#. ``git cherry-pick -x abcdef0``
#. Run regression tests.
-#. ``cd $PROJ.src``. Run the ``svn commit`` command printed out by ``merge.sh``
- in step 2.
-
Release Final Tasks
-------------------
@@ -325,29 +319,24 @@ demo page.
Update Documentation
^^^^^^^^^^^^^^^^^^^^
-Review the documentation and ensure that it is up to date. The "Release Notes"
-must be updated to reflect new features, bug fixes, new known issues, and
-changes in the list of supported platforms. The "Getting Started Guide" should
-be updated to reflect the new release version number tag available from
-Subversion and changes in basic system requirements. Merge both changes from
-mainline into the release branch.
+Review the documentation in the release branch and ensure that it is up
+to date. The "Release Notes" must be updated to reflect new features, bug
+fixes, new known issues, and changes in the list of supported platforms.
+The "Getting Started Guide" should be updated to reflect the new release
+version number tag available from Subversion and changes in basic system
+requirements.
.. _tag:
Tag the LLVM Final Release
^^^^^^^^^^^^^^^^^^^^^^^^^^
-Tag the final release sources using the tag.sh script in utils/release.
+Tag the final release sources:
::
- $ ./tag.sh -release X.Y.Z -final
-
-Update the LLVM Demo Page
--------------------------
-
-The LLVM demo page must be updated to use the new release. This consists of
-using the new ``clang`` binary and building LLVM.
+ $ git tag -a llvmorg-X.Y.Z
+ $ git push https://github.com/llvm/llvm-project.git llvmorg-X.Y.Z
Update the LLVM Website
^^^^^^^^^^^^^^^^^^^^^^^
@@ -355,27 +344,22 @@ Update the LLVM Website
The website must be updated before the release announcement is sent out. Here
is what to do:
-#. Check out the ``www`` module from Subversion.
-
-#. Create a new sub-directory ``X.Y`` in the releases directory.
+#. Check out the ``www-releases`` module from GitHub.
-#. Commit the ``llvm``, ``test-suite``, ``clang`` source and binaries in this
- new directory.
+#. Create a new sub-directory ``X.Y.Z`` in the releases directory.
#. Copy and commit the ``llvm/docs`` and ``LICENSE.txt`` files into this new
- directory. The docs should be built with ``BUILD_FOR_WEBSITE=1``.
-
-#. Commit the ``index.html`` to the ``release/X.Y`` directory to redirect (use
- from previous release).
+ directory.
-#. Update the ``releases/download.html`` file with the new release.
+#. Update the ``releases/download.html`` file with links to the release
+ binaries on GitHub.
#. Update the ``releases/index.html`` with the new release and link to release
documentation.
-#. Finally, update the main page (``index.html`` and sidebar) to point to the
- new release and release announcement. Make sure this all gets committed back
- into Subversion.
+#. Finally checkout the llvm-www repo and update the main page
+ (``index.html`` and sidebar) to point to the new release and release
+ announcement.
Announce the Release
^^^^^^^^^^^^^^^^^^^^
More information about the llvm-commits
mailing list