RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-01-31 12:41:49 +01:00
Code Issues Projects Releases Wiki Activity

HowToReleaseLLVM: Clean up document and remove references to SVN

Browse Source 
Reviewed By: hans

Differential Revision: https://reviews.llvm.org/D80395
This commit is contained in:
Tom Stellard 2020-10-22 11:33:58 -07:00
parent 2a6511f2a7
commit 5454af6727
1 changed files with 46 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

108
docs/HowToReleaseLLVM.rst
View File

@ -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
::
#. Clear the release notes in trunk.
$ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XY llvm-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/cfe/branches/release_XY clang-X.Y
$ 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.
#. Check out the ``www-releases`` module from GitHub.
#. Create a new sub-directory ``X.Y`` in the releases directory.
#. 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``.
directory.
#. Commit the ``index.html`` to the ``release/X.Y`` directory to redirect (use
from previous release).
#. 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
^^^^^^^^^^^^^^^^^^^^