HowToReleaseLLVM: Clean up document and remove references to SVN

[efriedma]

llvm/docs/HowToReleaseLLVM.rst

97

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

336

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.

351

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.

295

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

316

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

317

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

327

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

340

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.

353

another Subversion mention here :-)

[tstellar]

llvm/docs/HowToReleaseLLVM.rst

317

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

[hans]

llvm/docs/HowToReleaseLLVM.rst

317

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

[tstellar]

Address review comments.

llvm/docs/HowToReleaseLLVM.rst

327

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

336

I will take a look at this.

[hans]

llvm/docs/HowToReleaseLLVM.rst

327

Yes.

[tstellar]

Add example for tagging the -init tag.

[hans]

lgtm, thanks!

llvm/docs/HowToReleaseLLVM.rst

 release process to begin.  Specifically, it involves:
 
 * Creating the release branch,
 
 * Setting version numbers, 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:
-
-   ::
-
-     $ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XY llvm-X.Y
-
-     $ 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
+#. Create the release branch from the last known good revision.
+   The branch's name is release/X.x where ``X`` is the major version number and ``x``
+   is just the letter ``x``.
 
 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``').
+Update it on mainline as well to be the next version ('``X+1.Ysvn``').
 
 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 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:
+Use the git cherry-pick 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
 -------------------
 
 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.
 
 .. _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 llvmog-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.
-
 #. 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).
 
 #. Update the ``releases/download.html`` file with the new release.
 
 #. 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.
 
 Announce the Release
 ^^^^^^^^^^^^^^^^^^^^
 
 Send an email to the list announcing the release, pointing people to all the
 relevant documentation, download pages and bugs fixed.