Lines Matching refs:release

12 This document contains information about testing the release candidates that
13 will ultimately be the next LLVM release. For more information on how to
14 manage the actual release, please refer to :doc:`HowToReleaseLLVM`.
19 Once the release process starts, the Release Manager will ask for volunteers,
22 * Test and benchmark the previous release
24 * Test and benchmark each release candidate, comparing to the previous release
29 * Make sure the critical bugs get fixed and merged to the next release candidate
33 release.
41 * The stage in the release. Less critical bugs should be considered to be
52 The scripts are in the ``utils/release`` directory.
54 test-release.sh
64 To run the script on a specific release candidate run::
66    ./test-release.sh \
67         -release 3.3 \
79 * On the pre-release, you should change ``-rc 1`` to ``-final``. On RC2,
82 * On non-release testing, you can use ``-final`` in conjunction with
86 * For release candidates, you need ``-test-asserts``, or it won't create a
87   "Release+Asserts" directory, which is needed for release testing and
136 It should have no new regressions, compared to the previous release or release
145 the release to proceed. They can be set as "known failures" and to be
148 .. _pre-release-process:
156 When the release process is announced on the mailing list, you should prepare
157 for the testing, by applying the same testing you'll do on the release
158 candidates, on the previous release.
162 * Download the previous release sources from
165 * Run the test-release.sh script on ``final`` mode (change ``-rc 1`` to
186 When the Release Manager sends you the release candidate, download all sources,
188 to them), and run the release test as above.
192 * Download the current candidate sources from where the release manager points
199   where the release manager can grab it.
201 Once the release manages announces that the latest candidate is the good one,
210 * Make it available for the release manager to download
220 If you found regressions or failures when comparing a release candidate with the
221 previous release, follow the rules below:
226 * Check-all tests should be fixed before the next release candidate, but can
230   release candidates.
232 * New features or recent big changes, when close to the release, should have