Lines Matching refs:release

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`.
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 and candidates
28 * Make sure the critical bugs get fixed and merged to the next release candidate
31 should be fixed before the next candidate and what can wait until the next release.
39 * The stage in the release. Less critical bugs should be considered to be fixed between
50 The scripts are in the ``utils/release`` directory.
52 test-release.sh
60 To run the script on a specific release candidate run::
62    ./test-release.sh \
63         -release 3.3 \
74 * On the pre-release, you should change ``-rc 1`` to ``-final``. On RC2, change it to ``-rc 2`` and…
76 * On non-release testing, you can use ``-final`` in conjunction with ``-no-checkout``, but you'll h…
79 * For release candidates, you need ``-test-asserts``, or it won't create a "Release+Asserts" direct…
80   which is needed for release testing and benchmarking. This will take twice as long.
119 It should have no new regressions, compared to the previous release or release candidate. You don't…
125 as important, but not necessarily blocking the release to proceed. They can be set as "known failur…
128 .. _pre-release-process:
136 When the release process is announced on the mailing list, you should prepare
137 for the testing, by applying the same testing you'll do on the release candidates,
138 on the previous release.
142 * Download the previous release sources from http://llvm.org/releases/download.html.
144 * Run the test-release.sh script on ``final`` mode (change ``-rc 1`` to ``-final``).
163 When the Release Manager sends you the release candidate, download all sources,
165 to them), and run the release test as above.
169 * Download the current candidate sources from where the release manager points you
176   where the release manager can grab it.
178 Once the release manages announces that the latest candidate is the good one, you
186 * Make it available for the release manager to download
196 If you found regressions or failures when comparing a release candidate with the
197 previous release, follow the rules below:
202 * Check-all tests should be fixed before the next release candidate, but can wait
206   release candidates.
208 * New features or recent big changes, when close to the release, should have done