Lines Matching +full:- +full:- +full:branch +full:- +full:repo +full:- +full:token
8 This document contains information about successfully releasing LLVM ---
9 including sub-projects: e.g., ``clang`` and ``compiler-rt`` --- to the public.
21 LLVM is released on a time based schedule --- with major releases roughly
25 there are large number of bug-fixes in the stable branch or a critical bug
32 -----------------------
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**
47 **X.1.1** **8 weeks after branch**
48 **X.1.2** **10 weeks after branch**
49 **X.1.3** **12 weeks after branch**
50 **X.1.4** **14 weeks after branch**
51 **X.1.5** **16 weeks after branch**
52 **X.1.6 (if necessary)** **18 weeks after branch**
56 -----------------------
59 this at least 3 weeks before the -rc1 release.
61 * Create release branch and begin release process.
65 fixed. Patches are merged from mainline into the release branch. Also, all
80 * Do bug-fix releases every two weeks until X.1.5 or X.1.6 (if necessary).
89 ----------------------------
96 * Creating the release branch, and
100 Create Release Branch
103 Branch the Git trunk using the following procedure:
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
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
127 to X.1.0git (where ``X`` is the major version of the branch.)
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``.
145 $ git tag -sa llvmorg-X.Y.Z-rcN
147 The pre-packaged source tarballs will be automatically generated via the
157 $ for f in *.xz; do gh attestation verify --owner llvm $f && gpg -b $f; done
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>
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.
182 ------------------------------
196 ----------------
218 Infrastructure - Release Testers). <https://discourse.llvm.org/c/infrastructure/release-testers/66>`_
224 -----------------
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``
268 ---------------------
277 -----------------
279 Instructions for requesting a backport to a stable branch can be found :doc:`here <GitHub>`.
282 ---------------------------------
289 https://github.com/llvm/llvm-project/issues?q=is%3Aissue+milestone%3A%22LLVM+14.0.5+Release%22+no%3Aproject+
301 using the /cherry-pick or /branch comments if this has not been done already.
310 for committing to the release branch.
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
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
340 improvements, or completion of features that were started before the branch
356 -------------------
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
381 $ git tag -sa llvmorg-X.Y.Z
382 $ git push https://github.com/llvm/llvm-project.git llvmorg-X.Y.Z
390 #. Check out the ``www-releases`` module from GitHub.
392 #. Create a new sub-directory ``X.Y.Z`` in the releases directory.
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
421 $ git log --format="- %aN: [%s (%h)](https://github.com/llvm/llvm-project/commit/%H)" llvmorg-X.1.N-1..llvmorg-X.1.N
424 homepage (from the llvm-www repo) in the "Release Emails" section.