docs/ReleaseProcess.rst

   1 =============================
   2 How To Validate a New Release
   3 =============================
   4
   5 .. contents::
   6    :local:
   7    :depth: 1
   8
   9 Introduction
  10 ============
  11
  12 This document contains information about testing the release candidates that will
  13 ultimately be the next LLVM release. For more information on how to manage the
  14 actual release, please refer to :doc:`HowToReleaseLLVM`.
  15
  16 Overview of the Release Process
  17 -------------------------------
  18
  19 Once the release process starts, the Release Manager will ask for volunteers,
  20 and it'll be the role of each volunteer to:
  21
  22 * Test and benchmark the previous release
  23
  24 * Test and benchmark each release candidate, comparing to the previous release and candidates
  25
  26 * Identify, reduce and report every regression found during tests and benchmarks
  27
  28 * Make sure the critical bugs get fixed and merged to the next release candidate
  29
  30 Not all bugs or regressions are show-stoppers and it's a bit of a grey area what
  31 should be fixed before the next candidate and what can wait until the next release.
  32
  33 It'll depend on:
  34
  35 * The severity of the bug, how many people it affects and if it's a regression or a
  36   known bug. Known bugs are "unsupported features" and some bugs can be disabled if
  37   they have been implemented recently.
  38
  39 * The stage in the release. Less critical bugs should be considered to be fixed between
  40   RC1 and RC2, but not so much at the end of it.
  41
  42 * If it's a correctness or a performance regression. Performance regression tends to be
  43   taken more lightly than correctness.
  44
  45 .. _scripts:
  46
  47 Scripts
  48 =======
  49
  50 The scripts are in the ``utils/release`` directory.
  51
  52 test-release.sh
  53 ---------------
  54
  55 This script will configure and compile LLVM+Clang (+ most add-ons, like ``compiler-rt``,
  56 ``libcxx`` and ``clang-extra-tools``) in three stages, and will test the final stage.
  57 It'll have installed the final binaries on the Phase3/Release+Asserts directory, and
  58 that's the one you should use for the test-suite and other external tests.
  59
  60 Tip: For some reason, the script bails on ARM because of path mismatch on configure.
  61 The solution was to add a symlink inside the rc1 directory to the llvm.src directory::
  62
  63    mkdir rc1
  64    cd rc1
  65    ln -s ../../llvm.src
  66    cd ..
  67
  68 To run the script, you must be on the source directory and pass the right options, for example::
  69
  70    ./utils/release/test-release.sh \
  71                       -release 3.3 \
  72                       -rc 1 \
  73                       -no-checkout \
  74                       -no-64bit \
  75                       -test-asserts \
  76                       -no-compare-files
  77
  78 Each system will require different options. For instance, x86_64 will obviously not need
  79 ``-no-64bit`` while 32-bit systems will, or the script will fail.
  80
  81 The important flags to get right are:
  82
  83 * On the pre-release, you should change ``-rc 1`` to ``-final``. On RC2, change it to ``-rc 2`` and so on.
  84
  85 * On both previous release and candidates you must pass ``-no-checkout`` or it'll get the SVN trunk.
  86
  87 * You need ``-test-asserts``, or it won't create a "Release+Asserts" directory, which is needed for
  88   release testing and benchmarking.
  89
  90 This script builds three phases of Clang+LLVM twice each (Release and Release+Asserts), so use
  91 screen or nohup to avoid headaches, since it'll take a long time.
  92
  93 Use the ``--help`` option to see all the options and chose it according to your needs.
  94
  95
  96 findRegressions-nightly.py
  97 --------------------------
  98
  99 TODO
 100
 101 .. _test-suite:
 102
 103 Test Suite
 104 ==========
 105
 106 .. contents::
 107    :local:
 108
 109 Follow the `LNT Quick Start Guide <http://llvm.org/docs/lnt/quickstart.html>`__ link on how to set-up the test-suite
 110
 111 An example on the run command line, assuming you created a link from the correct
 112 install directory to ``~/devel/llvm/install``::
 113
 114    ./sandbox/bin/python sandbox/bin/lnt runtest \
 115        nt \
 116        -j4 \
 117        --sandbox sandbox \
 118        --test-suite ~/devel/llvm/test/test-suite \
 119        --cc ~/devel/llvm/install/bin/clang \
 120        --cxx ~/devel/llvm/install/bin/clang++
 121
 122 .. _pre-release-process:
 123
 124 Pre-Release Process
 125 ===================
 126
 127 .. contents::
 128    :local:
 129
 130 When the release process is announced on the mailing list, you should prepare
 131 for the testing, by applying the same testing you'll do on the release candidates,
 132 on the previous release.
 133
 134 You should:
 135
 136 * Download the previous release sources from http://llvm.org/releases/download.html.
 137
 138 * Run the test-release.sh script on ``final`` mode (change ``-rc 1`` to ``-final``).
 139
 140 * Once all three stages are done, it'll test the final stage.
 141
 142 * Using the ``Phase3/Release+Asserts/llvmObj-MAJ.MIN-rcN.install`` base, run the test-suite.
 143
 144 If the final phase's ``make check-all`` failed, it's a good idea to also test the
 145 intermediate stages by going on the obj directory and running ``make check-all`` to find
 146 if there's at least one stage that passes (helps when reducing the error for bug report
 147 purposes).
 148
 149 .. _release-process:
 150
 151 Release Process
 152 ===============
 153
 154 .. contents::
 155    :local:
 156
 157 When the Release Manager sends you the release candidate, download all sources,
 158 unzip on the same directory (there will be sym-links from the appropriate places
 159 to them), and run the release test as above.
 160
 161 You should:
 162
 163 * Download the current candidate sources from where the release manager points you
 164   (ex. http://llvm.org/pre-releases/3.3/rc1/).
 165
 166 * Repeat the steps above with ``-rc 1``, ``-rc 2`` etc modes and run the test-suite
 167   the same way.
 168
 169 * Compare the results, report all errors on Bugzilla and publish the binary blob
 170   where the release manager can grab it.
 171
 172 Once the release manages announces that the latest candidate is the good one, you
 173 have to pack the ``Release`` (no Asserts) install directory on ``Phase3`` and that
 174 will be the official binary.
 175
 176 .. _bug-reporting:
 177
 178 Bug Reporting Process
 179 =====================
 180
 181 .. contents::
 182    :local:
 183
 184 If you found regressions or failures when comparing a release candidate with the
 185 previous release, follow the rules below:
 186
 187 * Critical bugs on compilation should be fixed as soon as possible, possibly before
 188   releasing the binary blobs.
 189
 190 * Check-all tests should be fixed before the next release candidate, but can wait
 191   until the test-suite run is finished.
 192
 193 * Bugs in the test suite or unimportant check-all tests can be fixed in between
 194   release candidates.
 195
 196 * New features or recent big changes, when close to the release, should have done
 197   in a way that it's easy to disable. If they misbehave, prefer disabling them than
 198   releasing an unstable (but untested) binary package.