Lines Matching refs:release
13 If you're looking for the document on how to test the release candidates and
23 The release manager will determine if and when to make a dot release based
31 The release process is roughly as follows:
34 date. Announce release schedule to the LLVM community and update the website.
36 * Create release branch and begin release process.
38 * Send out release candidate sources for first round of testing. Testing lasts
40 fixed. Patches are merged from mainline into the release branch. Also, all
43 release.
45 * Generate and send out the second release candidate sources. Only *critical*
49 * The release notes are updated.
51 * Finally, release!
53 The release process will be accelerated for dot releases. If the first round
54 of testing finds no critical bugs and no regressions since the last major release,
67 release process to begin. Specifically, it involves:
71 * Creating the release branch, and
73 * Tagging release candidates for the release team to begin testing.
80 #. Remind developers that the release branching is imminent and to refrain from
95 #. Clear the release notes in trunk.
97 #. Create the release branch from the last known good revision from before the
98 version bump. The branch's name is release/X.x where ``X`` is the major version
107 After creating the LLVM release branch, update the release branches'
111 for the next release.
116 Tag release candidates:
123 be done with the export.sh script in utils/release.
125 Tarballs, release binaries, or any other release artifacts must be uploaded to
126 GitHub. This can be done using the github-upload-release.py script in utils/release.
130 …$ github-upload-release.py upload --token <github-token> --release X.Y.Z-rcN --files <release_file…
134 $ ./export.sh -release X.Y.Z -rc $RC
156 A release is qualified when it has no regressions from the previous release (or
163 regressions with the ``test-suite`` in relation to the previous release.
166 each product and only include things on the list. Every release will have
168 software. We need a very concrete and definitive release criteria that
172 which must be satisfied before a release can go out.
177 A few developers in the community have dedicated time to validate the release
178 candidates and volunteered to be the official release testers for each
182 to the server, and will be the minimum tests *necessary* for the release to
187 release is out, all bugs reported will have to go on the next stable release.
189 The official release managers are:
194 The official release testers are volunteered from the community and have
196 them, you should email the ``release-testers@lists.llvm.org`` mailing list.
204 Once all testing has been completed and appropriate bugs filed, the release
207 We ask that all LLVM developers test the release in any the following ways:
225 #. Run the :doc:`release process <ReleaseProcess>`, if your platform is
227 only if they were not reported by the official release tester for that
230 We also ask that the OS distribution release managers test their packages with
231 the first candidate of every release, and report any *new* errors in Bugzilla.
232 If the bug can be reproduced with an unpatched upstream version of the release
234 release blocker.
237 second release candidate is tagged.
242 the release is determined to be ready and the release manager may move onto the
249 should be filled in a bug in Bugzilla with the priority *release blocker* and
250 blocking a specific release.
264 be merged into a release branch:
266 #. Use the ``utils/release/merge-request.sh`` script which will automatically
268 12345 be merged into the branch for the 5.0.1 release:
269 …``llvm.src/utils/release/merge-request.sh -stable-version 5.0 -r 12345 -user bugzilla@example.com``
273 it as a blocker of the current release bug. Release bugs are given aliases
274 in the form of release-x.y.z, so to mark a bug as a blocker for the 5.0.1
275 release, just enter release-5.0.1 in the "Blocks" field.
278 the release manager.
285 Below are the rules regarding patching the release branch:
287 #. Patches applied to the release branch may only be applied by the release
288 manager, the official release testers or the code owners with approval from
289 the release manager.
301 the previous major release. Only bug-fixes will be accepted.
306 Use the ``git cherry-pick -x`` command to merge patches to the release branch:
315 The final stages of the release process involves tagging the "final" release
316 branch, updating documentation that refers to the release, and updating the
322 Review the documentation in the release branch and ensure that it is up
325 The "Getting Started Guide" should be updated to reflect the new release
334 Tag the final release sources:
344 The website must be updated before the release announcement is sent out. Here
354 #. Update the ``releases/download.html`` file with links to the release
357 #. Update the ``releases/index.html`` with the new release and link to release
361 (``index.html`` and sidebar) to point to the new release and release
367 Send an email to the list announcing the release, pointing people to all the