Lines Matching +full:- +full:release
2 How To Release LLVM To The Public
8 This document contains information about successfully releasing LLVM ---
9 including sub-projects: e.g., ``clang`` and ``compiler-rt`` --- to the public.
10 It is the Release Manager's responsibility to ensure that a high quality build
13 If you're looking for the document on how to test the release candidates and
18 Release Timeline
21 LLVM is released on a time based schedule --- with major releases roughly
23 The release manager will determine if and when to make a dot release based
25 there are large number of bug-fixes in the stable branch or a critical bug
31 Annual Release Schedule
32 -----------------------
34 Here is the annual release schedule for LLVM. This is meant to be a
35 guide, and release managers are not required to follow this exactly.
39 Release Approx. Date
41 *release branch: even releases* *4th Tue in January*
42 *release branch: odd releases* *4th Tue in July*
43 X.1.0-rc1 3 days after branch.
44 X.1.0-rc2 2 weeks after branch.
45 X.1.0-rc3 4 weeks after branch
46 **X.1.0-final** **6 weeks after branch**
55 Release Process Summary
56 -----------------------
58 * Announce release schedule to the LLVM community and update the website. Do
59 this at least 3 weeks before the -rc1 release.
61 * Create release branch and begin release process.
63 * Send out release candidate sources for first round of testing. Testing lasts
65 fixed. Patches are merged from mainline into the release branch. Also, all
68 release.
70 * Generate and send out the second release candidate sources. Only *critical*
74 * The release notes are updated.
76 * Finally, release!
78 * Announce bug fix release schedule to the LLVM community and update the website.
80 * Do bug-fix releases every two weeks until X.1.5 or X.1.6 (if necessary).
82 Release Process
88 Release Administrative Tasks
89 ----------------------------
92 release process to begin. Specifically, it involves:
96 * Creating the release branch, and
98 * Tagging release candidates for the release team to begin testing.
100 Create Release Branch
105 #. Remind developers that the release branching is imminent and to refrain from
113 #. Bump the version in trunk to N.0.0git and tag the commit with llvmorg-N-init.
118 $ git tag -sa llvmorg-N-init
120 #. Clear the release notes in trunk.
122 #. Create the release branch from the last known good revision from before the
123 version bump. The branch's name is release/X.x where ``X`` is the major version
126 #. On the newly-created release branch, immediately bump the version
129 #. All tags and branches need to be created in both the llvm/llvm-project and
130 llvm/llvm-test-suite repos.
135 After creating the LLVM release branch, update the release branches'
136 version with the script in ``llvm/utils/release/bump-version.py``.
138 Tagging the LLVM Release Candidates
141 Tag release candidates:
145 $ git tag -sa llvmorg-X.Y.Z-rcN
147 The pre-packaged source tarballs will be automatically generated via the
148 "Release Sources" workflow on GitHub. This workflow will create an artifact
149 containing all the release tarballs and the artifact attestation. The
150 Release Manager should download the artifact, verify the tarballs, sign them,
151 and then upload them to the release page.
157 $ for f in *.xz; do gh attestation verify --owner llvm $f && gpg -b $f; done
159 Tarballs, release binaries, or any other release artifacts must be uploaded to
160 GitHub. This can be done using the github-upload-release.py script in utils/release.
164 $ github-upload-release.py upload --token <github-token> --release X.Y.Z-rcN --files <release_files>
173 That process will perform both Release+Asserts and Release builds but only
174 pack the Release build for upload. You should use the Release+Asserts sysroot,
175 normally under ``final/Phase3/Release+Asserts/llvmCore-3.8.1-RCn.install/``,
176 for test-suite and run-time benchmarks, to make sure nothing serious has
177 passed through the net. For compile-time benchmarks, use the Release version.
181 Release Qualification Criteria
182 ------------------------------
184 There are no official release qualification criteria. It is up to the
185 the release manager to determine when a release is ready. The release manager
188 release.
192 kind of bugs that are critical enough to block a release would be a major regression
193 from a previous release.
196 ----------------
198 A few developers in the community have dedicated time to validate the release
199 candidates and volunteered to be the official release testers for each
203 to the server, and will be the minimum tests *necessary* for the release to
208 release is out, all bugs reported will have to go on the next stable release.
210 The official release managers are:
215 The official release testers are volunteered from the community and have
218 Infrastructure - Release Testers). <https://discourse.llvm.org/c/infrastructure/release-testers/66>`_
224 -----------------
226 Once all testing has been completed and appropriate bugs filed, the release
229 We ask that all LLVM developers test the release in any the following ways:
231 #. Download ``llvm-X.Y``, ``llvm-test-X.Y``, and the appropriate ``clang``
235 #. Download ``llvm-X.Y``, ``llvm-test-X.Y``, and the ``clang`` sources. Compile
239 #. Download ``llvm-X.Y``, ``llvm-test-X.Y``, and the appropriate ``clang``
243 #. Download ``llvm-X.Y``, ``llvm-test-X.Y``, and the appropriate ``clang``
247 #. Run the :doc:`release process <ReleaseProcess>`, if your platform is
249 only if they were not reported by the official release tester for that
252 We also ask that the OS distribution release managers test their packages with
253 the first candidate of every release, and report any *new* errors in GitHub.
254 If the bug can be reproduced with an unpatched upstream version of the release
256 release blocker.
259 second release candidate is tagged.
264 the release is determined to be ready and the release manager may move onto the
268 ---------------------
271 should be filled in a bug in GitHub and added to the release milestone.
277 -----------------
282 ---------------------------------
286 #. Search for bugs with a Release Milestone that have not been added to the
287 "Release Status" github project:
289 https://github.com/llvm/llvm-project/issues?q=is%3Aissue+milestone%3A%22LLVM+14.0.5+Release%22+no%3Aproject+
291 Replace 14.0.5 in this query with the version from the Release Milestone being
294 Add these bugs to the "Release Status" project.
296 #. Navigate to the `Release Status project <https://github.com/orgs/llvm/projects/3>`_
297 to see the list of bugs that are being considered for the release.
301 using the /cherry-pick or /branch comments if this has not been done already.
310 for committing to the release branch.
312 #. Once a bug has been reviewed, add the release:reviewed label and update the
317 #. Once the pull request has been merged push it to the official release branch
318 with the script ``llvm/utils/git/sync-release-repo.sh``.
321 the git hashes from the release branch. Add the release:merged label to the issue
325 Release Patch Rules
326 -------------------
328 Below are the rules regarding patching the release branch:
330 #. Patches applied to the release branch may only be applied by the release
331 manager, the official release testers or the maintainers with approval from
332 the release manager.
334 #. Release managers are encouraged, but not required, to get approval from a
336 then release managers can ask approval from patch reviewers or other
341 was created. As with all phases, release managers and maintainers can reject
347 #. *Before RC3/Final Major Release* Patches should be limited to critical
352 ABI compatibility with the previous major release.
355 Release Final Tasks
356 -------------------
358 The final stages of the release process involves tagging the "final" release
359 branch, updating documentation that refers to the release, and updating the
365 Review the documentation in the release branch and ensure that it is up
366 to date. The "Release Notes" must be updated to reflect new features, bug
368 The "Getting Started Guide" should be updated to reflect the new release
374 Tag the LLVM Final Release
377 Tag the final release sources:
381 $ git tag -sa llvmorg-X.Y.Z
382 $ git push https://github.com/llvm/llvm-project.git llvmorg-X.Y.Z
387 The website must be updated before the release announcement is sent out. Here
390 #. Check out the ``www-releases`` module from GitHub.
392 #. Create a new sub-directory ``X.Y.Z`` in the releases directory.
397 #. Update the ``releases/download.html`` file with links to the release
400 #. Update the ``releases/index.html`` with the new release and link to release
403 #. After you push the changes to the www-releases repo, someone with admin
404 access must login to prereleases-origin.llvm.org and manually pull the new
405 changes into /data/www-releases/. This is where the website is served from.
407 #. Finally checkout the llvm-www repo and update the main page
408 (``index.html`` and sidebar) to point to the new release and release
411 Announce the Release
415 once all the release tasks are complete. For X.1.0 releases, make sure to include a
416 link to the release notes in the post. For X.1.1+ releases, generate a changelog
421 $ git log --format="- %aN: [%s (%h)](https://github.com/llvm/llvm-project/commit/%H)" llvmorg-X.1.N-1..llvmorg-X.1.N
423 Once the release has been announced add a link to the announcement on the llvm
424 homepage (from the llvm-www repo) in the "Release Emails" section.