Lines Matching full:release
2 How To Release LLVM To The Public
14 is the Release Manager's responsibility to ensure that a high quality build of
17 If you're looking for the document on how to test the release candidates and
22 Release Timeline
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!
54 Release Process
60 Release Administrative Tasks
64 release process to begin. Specifically, it involves:
66 * Creating the release branch,
70 * Tagging release candidates for the release team to begin testing.
72 Create Release Branch
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.
132 Build the LLVM Release Candidates
135 Create release candidates for ``llvm``, ``clang``, ``dragonegg``, and the LLVM
136 ``test-suite`` by tagging the branch with the respective release candidate
137 number. For instance, to create **Release Candidate 1** you would issue the
158 Similarly, **Release Candidate 2** would be named ``RC2`` and so on. This keeps
159 a permanent copy of the release candidate around for people to export and build
163 The Release Manager may supply pre-packaged source tarballs for users. This can
178 Building the Release
182 errors and warnings in Debug, Release+Asserts, and Release builds. If all
183 builds are clean, then the release passes Build Qualification.
192 | Release+Asserts | ``ENABLE_OPTIMIZED=1`` |
194 | Release | ``ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1`` |
200 Build ``Debug``, ``Release+Asserts``, and ``Release`` versions
207 Creating the ``clang`` binary distribution (Debug/Release+Asserts/Release)
213 #. Build both a Debug and Release version of clang. The binary will be the
214 Release build.
242 Release Qualification Criteria
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
332 Release Patch Rules
335 Below are the rules regarding patching the release branch:
337 #. Patches applied to the release branch may only be applied by the release
349 Release Final Tasks
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
359 Review the documentation and ensure that it is up to date. The "Release Notes"
362 be updated to reflect the new release version number tag available from
364 mainline into the release branch.
368 Tag the LLVM Final Release
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
421 Announce the Release
424 Have Chris send out the release announcement when everything is finished.
