Skip to content

[llvm][docs] Minor fixes and improvements for release process #151956

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

[llvm][docs] Minor fixes and improvements for release process #151956

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 24 additions & 29 deletions llvm/docs/HowToReleaseLLVM.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -115,11 +115,9 @@ Branch the Git trunk using the following procedure:
examining nightly tester and buildbot results.

#. 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``.
If ``X`` is the version to be released, then ``N`` is ``X + 1``. ::

::

$ git tag -sa llvmorg-N-init
$ git tag -sa llvmorg-N-init

#. Clear the release notes in trunk.

Expand Down Expand Up @@ -149,10 +147,12 @@ Tag release candidates:
$ git tag -sa llvmorg-X.Y.Z-rcN

The pre-packaged source tarballs will be automatically generated via the
"Release Sources" workflow on GitHub. This workflow will create an artifact
containing all the release tarballs and the artifact attestation. The
Release Manager should download the artifact, verify the tarballs, sign them,
and then upload them to the release page.
`Release Sources
<https://github.com/llvm/llvm-project/actions/workflows/release-sources.yml>`_
workflow on GitHub. This workflow will create an artifact containing all the
release tarballs and the artifact attestation. The Release Manager should
download the artifact, verify the tarballs, sign them, and then upload them to
the release page.

::

Expand Down Expand Up @@ -221,8 +221,9 @@ consistently validated and released binaries for their targets/OSs. To contact
them, you should post on the `Discourse forums (Project
Infrastructure - Release Testers). <https://discourse.llvm.org/c/infrastructure/release-testers/66>`_

The official testers list is in the file ``RELEASE_TESTERS.TXT``, in the ``LLVM``
repository.
The official testers list is in the file `RELEASE_TESTERS.TXT
<https://github.com/llvm/llvm-project/blob/main/llvm/RELEASE_TESTERS.TXT>`_, in
the LLVM repository.

Community Testing
-----------------
Expand Down Expand Up @@ -280,7 +281,8 @@ from the Milestone. Debugging can continue, but on trunk.
Backport Requests
-----------------

Instructions for requesting a backport to a stable branch can be found :doc:`here <GitHub>`.
Instructions for requesting a backport to a stable branch can be found
:ref:`here <backporting>`.

Triaging Bug Reports for Releases
---------------------------------
Expand All @@ -305,26 +307,19 @@ This section describes how to triage bug reports:
using the /cherry-pick or /branch comments if this has not been done already.

#. If a bug has been fixed and has a pull request created for backporting it,
then update its status to "Needs Review" and notify a knowledgeable reviewer.
Usually you will want to notify the person who approved the patch in Phabricator,
but you may use your best judgement on who a good reviewer would be. Once
you have identified the reviewer(s), assign the issue to them and mention
them (i.e @username) in a comment and ask them if the patch is safe to backport.
You should also review the bug yourself to ensure that it meets the requirements
for committing to the release branch.
then update its status to "Needs Review" and notify a knowledgeable
reviewer. Usually you will want to notify the person who approved the
patch, but you may use your best judgement on who a good reviewer would be.
Once you have identified the reviewer(s), assign the issue to them and
mention them (i.e @username) in a comment and ask them if the patch is safe
to backport. You should also review the bug yourself to ensure that it
meets the requirements for committing to the release branch.

#. Once a bug has been reviewed, add the release:reviewed label and update the
issue's status to "Needs Merge". Check the pull request associated with the
issue. If all the tests pass, then the pull request can be merged. If not,
then add a comment on the issue asking someone to take a look at the failures.

#. Once the pull request has been merged push it to the official release branch
with the script ``llvm/utils/git/sync-release-repo.sh``.

Then add a comment to the issue stating that the fix has been merged along with
the git hashes from the release branch. Add the release:merged label to the issue
and close it.


Release Patch Rules
-------------------
Expand Down Expand Up @@ -368,9 +363,8 @@ Update Documentation
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.
The :doc:`GettingStarted` page should be updated to reflect the new release
version number tag and changes in basic system requirements.

.. _tag:

Expand All @@ -390,7 +384,8 @@ 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-releases`` module from GitHub.
#. Check out the `www-releases <https://github.com/llvm/www-releases>`_ repo
from GitHub.

#. Create a new sub-directory ``X.Y.Z`` in the releases directory.

Expand Down
Loading