HowToReleaseLLVM: Clean up document and remove references to SVN

[efriedma]

llvm/docs/HowToReleaseLLVM.rst

108

I think this is of the form X.0.0git now?

346–347

Not really a question about this patch, but it looks like this step might be have been skipped for a few past releases? https://releases.llvm.org/9.0.1/docs/index.html and https://releases.llvm.org/7.1.0/docs/index.html (which are linked from https://releases.llvm.org/) are 404.

359–360

Missing step "checkout llvm-www"?

[hans]

Thanks! This doc could certainly use some attention :-) I put some comments, feel free to ignore if you don't want to get into all of them now.

llvm/docs/HowToReleaseLLVM.rst

75

Actually, I always bump the trunk version number before creating the branch, and then create the branch from the commit right before the version number bump. So the dance is more like:

1. Bump trunk version (and also clear release notes; not necessarily in the same commit)
2. Create release branch from right before the bump
3. Drop "git" prefix on the git branch.

Also the version bump gets tagged with "llvmorg-x-init" to generate nice "git describe" results.

78

Maybe note somewhere that the same should be done for the 'test-suite' repo, since the test and export scripts expect it to be versioned similarly.

306

maybe "use the git cherry-pick command with the -x option" to really spell it out so people don't forget the -x part.

322–327

"Merge both changes from mainline into the release branch." sounds wrong. The changes should be done on the release branch directly.

328

One thing that's easy to miss is that some docs must be generated. This is my go-to command for that:

bin/clang-tblgen -gen-diag-docs -I../clang/include \
      -I../clang/include/clang/Basic/ \
      ../clang/include/clang/Basic/Diagnostic.td -o \
      ../clang/docs/DiagnosticsReference.rst && \
bin/clang-tblgen -gen-attr-docs -I../clang/include \
        ../clang/include/clang/Basic/Attr.td -o \
        ../clang/docs/AttributeReference.rst && \
bin/clang-tblgen -gen-opt-docs -I../clang/include \
        -I../clang/include/clang/Driver -I../llvm/include \
        ../clang/include/clang/Driver/ClangOptionDocs.td -o \
        ../clang/docs/ClangCommandLineReference.rst

338–339

I've been doing "git tag -a", but I'm not sure if it makes any real difference?

351

These steps seem to refer to things that don't exist anymore, like BUILD_FOR_WEBSITE=1. Maybe they can be written a bit less specific: like check in the docs, update download.html to link to the binaries on github, etc. etc.

360–362

another Subversion mention here :-)

[tstellar]

llvm/docs/HowToReleaseLLVM.rst

328

I fixed this in trunk, so this should not be needed any more (LLVM 11+).

[hans]

llvm/docs/HowToReleaseLLVM.rst

328

Oooh, that's excellent, thanks! (For anyone following along, that was D72875).

[tstellar]

Address review comments.

llvm/docs/HowToReleaseLLVM.rst

338–339

Do you also use -a for the llvmorg-N-init tag?

346–347

I will take a look at this.

[hans]

llvm/docs/HowToReleaseLLVM.rst

338–339

Yes.

[tstellar]

Add example for tagging the -init tag.

[hans]

lgtm, thanks!

llvm/docs/HowToReleaseLLVM.rst

.. contents::
    :local:
 
 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.
-
-#. 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:
+#. 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``.
 
-   ::
 
-     $ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XY llvm-X.Y
+  $ git tag -a llvmorg-N-init
 
-     $ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XY clang-X.Y
+#. Clear the release notes in trunk.
 
-     $ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XY test-suite-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``.
+
+#. 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.
 
 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
 pack the Release build for upload. You should use the Release+Asserts sysroot,
 normally under ``final/Phase3/Release+Asserts/llvmCore-3.8.1-RCn.install/``,
 for test-suite and run-time benchmarks, to make sure nothing serious has 
 passed through the net. For compile-time benchmarks, use the Release version.
 
#. During the remaining rounds of testing, only patches that fix critical
    regressions may be applied.
 
 #. For dot releases all patches must maintain both API and ABI compatibility with
    the previous major release.  Only bug-fixes will be accepted.
 
 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:
-
-#. ``svn co https://llvm.org/svn/llvm-project/$PROJ/branches/release_XX
-   $PROJ.src``
+Use the ``git cherry-pick -x`` command to merge patches to the release branch:
 
-#. ``$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
 -------------------
 
 The final stages of the release process involves tagging the "final" release
 branch, updating documentation that refers to the release, and updating the
 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
 ^^^^^^^^^^^^^^^^^^^^^^^
 
 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``.
-
-#. 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
 ^^^^^^^^^^^^^^^^^^^^
 
 Send an email to the list announcing the release, pointing people to all the
 relevant documentation, download pages and bugs fixed.