Lines Matching refs:release
17 If you're looking for the document on how to test the release candidates and
30 releases, we cannot allow for a truncated form of release qualification.
32 The release process is roughly as follows:
35 date. Announce release schedule to the LLVM community and update the website.
37 * Create release branch and begin release process.
39 * Send out release candidate sources for first round of testing. Testing lasts
41 fixed. Patches are merged from mainline into the release branch. Also, all
44 release.
46 * Generate and send out the second release candidate sources. Only *critial*
50 * The release notes are updated.
52 * Finally, release!
64 release process to begin. Specifically, it involves:
66 * Creating the release branch,
70 * Tagging release candidates for the release team to begin testing.
77 #. Remind developers that the release branching is imminent and to refrain from
85 #. Create the release branch for ``llvm``, ``clang``, the ``test-suite``, and
87 ``release_XY``, where ``X`` is the major and ``Y`` the minor release
107 #. The Release Manager should switch to the release branch, because all changes
108 to the release will now be done in the branch. The easiest way to do this is
124 After creating the LLVM release branch, update the release branches'
130 for the next release.
135 Create release candidates for ``llvm``, ``clang``, ``dragonegg``, and the LLVM
136 ``test-suite`` by tagging the branch with the respective release candidate
159 a permanent copy of the release candidate around for people to export and build
183 builds are clean, then the release passes Build Qualification.
245 A release is qualified when it has no regressions from the previous release (or
251 each product and only include things on the list. Every release will have
253 software. We need a very concrete and definitive release criteria that
257 which must be satisfied before a release can go out.**
264 ``test-suite`` from the previous release.
279 | x86-32 | Linux | last release | llvm regression tests, |
283 | x86-32 | FreeBSD | last release | llvm regression tests, |
289 | x86-64 | Mac OS 10.X | last release | llvm regression tests, |
293 | x86-64 | Linux | last release | llvm regression tests, |
297 | x86-64 | FreeBSD | last release | llvm regression tests, |
305 Once all testing has been completed and appropriate bugs filed, the release
307 Ask that all LLVM developers test the release in 2 ways:
318 to the list. Verify that there are no regressions from the previous release.
319 The results are not used to qualify a release, but to spot other potential
324 second release candidate is tagged.
329 the release is determined to be ready and the release manager may move onto the
335 Below are the rules regarding patching the release branch:
337 #. Patches applied to the release branch may only be applied by the release
352 The final stages of the release process involves tagging the "final" release
353 branch, updating documentation that refers to the release, and updating the
362 be updated to reflect the new release version number tag available from
364 mainline into the release branch.
371 Tag the final release sources using the following procedure:
390 The LLVM demo page must be updated to use the new release. This consists of
396 The website must be updated before the release announcement is sent out. Here
409 #. Commit the ``index.html`` to the ``release/X.Y`` directory to redirect (use
410 from previous release).
412 #. Update the ``releases/download.html`` file with the new release.
414 #. Update the ``releases/index.html`` with the new release and link to release
418 new release and release announcement. Make sure this all gets committed back
424 Have Chris send out the release announcement when everything is finished.