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 * Announce bug fix release schedule to the LLVM community and update the website.
62 * Tag final release.
74 release process to begin. Specifically, it involves:
78 * Creating the release branch, and
80 * Tagging release candidates for the release team to begin testing.
87 #. Remind developers that the release branching is imminent and to refrain from
102 #. Clear the release notes in trunk.
104 #. Create the release branch from the last known good revision from before the
105 version bump. The branch's name is release/X.x where ``X`` is the major version
114 After creating the LLVM release branch, update the release branches'
118 for the next release.
123 Tag release candidates:
130 be done with the export.sh script in utils/release.
132 Tarballs, release binaries, or any other release artifacts must be uploaded to
133 GitHub. This can be done using the github-upload-release.py script in utils/release.
137 …$ github-upload-release.py upload --token <github-token> --release X.Y.Z-rcN --files <release_file…
141 $ ./export.sh -release X.Y.Z -rc $RC
163 There are no official release qualification criteria. It is up to the
164 the release manager to determine when a release is ready. The release manager
167 release.
171 kind of bugs that are critical enough to block a release would be a major regression
172 from a previous release.
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[email protected]`` 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.
281 to see the list of bugs that are being considered for the release.
294 for committing to the release branch.
296 #. Once a bug has been reviewed, add the release:reviewed label and update the
301 #. Once the pull request has been merged push it to the official release branch:
305 git checkout release/XX.x
306 git pull --ff-only https://github.com/llvm/llvm-project-release-prs release/XX.x
307 git push https://github.com/llvm/llvm-project release/XX.x:release/XX.x
310 the git hashes from the release branch. Add the release:merged label to the issue
317 Below are the rules regarding patching the release branch:
319 #. Patches applied to the release branch may only be applied by the release
320 manager, the official release testers or the code owners with approval from
321 the release manager.
325 is unreachable then release managers can ask approval from patch reviewers or
330 was created. As with all phases, release managers and code owners can reject
341 ABI compatibility with the previous major release.
347 Use the ``git cherry-pick -x`` command to merge patches to the release branch:
356 The final stages of the release process involves tagging the "final" release
357 branch, updating documentation that refers to the release, and updating the
363 Review the documentation in the release branch and ensure that it is up
366 The "Getting Started Guide" should be updated to reflect the new release
375 Tag the final release sources:
385 The website must be updated before the release announcement is sent out. Here
395 #. Update the ``releases/download.html`` file with links to the release
398 #. Update the ``releases/index.html`` with the new release and link to release
402 (``index.html`` and sidebar) to point to the new release and release
408 Send an email to the list announcing the release, pointing people to all the