From f42b14e2a8d04b6288635192051adf36423af2c1 Mon Sep 17 00:00:00 2001 From: Renato Golin Date: Wed, 12 Jun 2013 11:35:33 +0000 Subject: Update Release Process doc git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183825 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/ReleaseProcess.rst | 56 ++++++++++++++++++++++++++++++------------------- 1 file changed, 34 insertions(+), 22 deletions(-) diff --git a/docs/ReleaseProcess.rst b/docs/ReleaseProcess.rst index a6827556ec..c4bbc91c63 100644 --- a/docs/ReleaseProcess.rst +++ b/docs/ReleaseProcess.rst @@ -52,28 +52,19 @@ The scripts are in the ``utils/release`` directory. test-release.sh --------------- -This script will configure and compile LLVM+Clang (+ most add-ons, like ``compiler-rt``, +This script will check-out, configure and compile LLVM+Clang (+ most add-ons, like ``compiler-rt``, ``libcxx`` and ``clang-extra-tools``) in three stages, and will test the final stage. -It'll have installed the final binaries on the Phase3/Release+Asserts directory, and +It'll have installed the final binaries on the Phase3/Releasei(+Asserts) directory, and that's the one you should use for the test-suite and other external tests. -Tip: For some reason, the script bails on ARM because of path mismatch on configure. -The solution was to add a symlink inside the rc1 directory to the llvm.src directory:: +To run the script on a specific release candidate run:: - mkdir rc1 - cd rc1 - ln -s ../../llvm.src - cd .. - -To run the script, you must be on the source directory and pass the right options, for example:: - - ./utils/release/test-release.sh \ - -release 3.3 \ - -rc 1 \ - -no-checkout \ - -no-64bit \ - -test-asserts \ - -no-compare-files + ./test-release.sh \ + -release 3.3 \ + -rc 1 \ + -no-64bit \ + -test-asserts \ + -no-compare-files Each system will require different options. For instance, x86_64 will obviously not need ``-no-64bit`` while 32-bit systems will, or the script will fail. @@ -82,10 +73,13 @@ The important flags to get right are: * On the pre-release, you should change ``-rc 1`` to ``-final``. On RC2, change it to ``-rc 2`` and so on. -* On both previous release and candidates you must pass ``-no-checkout`` or it'll get the SVN trunk. +* On non-release testing, you can use ``-final`` in conjunction with ``-no-checkout``, but you'll have to + create the ``final`` directory by hand and link the correct source dir to ``final/llvm.src``. + +* For release candidates, you need ``-test-asserts``, or it won't create a "Release+Asserts" directory, + which is needed for release testing and benchmarking. This will take twice as long. -* You need ``-test-asserts``, or it won't create a "Release+Asserts" directory, which is needed for - release testing and benchmarking. +* On the final candidate you just need Release builds, and that's the binary directory you'll have to pack. This script builds three phases of Clang+LLVM twice each (Release and Release+Asserts), so use screen or nohup to avoid headaches, since it'll take a long time. @@ -108,6 +102,9 @@ Test Suite Follow the `LNT Quick Start Guide `__ link on how to set-up the test-suite +The binary location you'll have to use for testing is inside the ``rcN/Phase3/Release+Asserts/llvmCore-REL-RC.install``. +Link that directory to an easier location and run the test-suite. + An example on the run command line, assuming you created a link from the correct install directory to ``~/devel/llvm/install``:: @@ -119,6 +116,15 @@ install directory to ``~/devel/llvm/install``:: --cc ~/devel/llvm/install/bin/clang \ --cxx ~/devel/llvm/install/bin/clang++ +It should have no new regressions, compared to the previous release or release candidate. You don't need to fix +all the bugs in the test-suite, since they're not necessarily meant to pass on all architectures all the time. This is +due to the nature of the result checking, which relies on direct comparison, and most of the time, the failures are +related to bad output checking, rather than bad code generation. + +If the errors are in LLVM itself, please report every single regression found as blocker, and all the other bugs +as important, but not necessarily blocking the release to proceed. They can be set as "known failures" and to be +fix on a future date. + .. _pre-release-process: Pre-Release Process @@ -139,7 +145,7 @@ You should: * Once all three stages are done, it'll test the final stage. -* Using the ``Phase3/Release+Asserts/llvmObj-MAJ.MIN-rcN.install`` base, run the test-suite. +* Using the ``Phase3/Release+Asserts/llvmCore-MAJ.MIN-final.install`` base, run the test-suite. If the final phase's ``make check-all`` failed, it's a good idea to also test the intermediate stages by going on the obj directory and running ``make check-all`` to find @@ -173,6 +179,12 @@ Once the release manages announces that the latest candidate is the good one, yo have to pack the ``Release`` (no Asserts) install directory on ``Phase3`` and that will be the official binary. +* Rename (or link) ``clang+llvm-REL-ARCH-ENV`` to the .install directory + +* Tar that into the same name with ``.tar.gz`` extensioan from outside the directory + +* Make it available for the release manager to download + .. _bug-reporting: Bug Reporting Process -- cgit v1.2.3