Lines Matching +full:pull +full:- +full:requests
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 -----------------------
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**
56 -----------------------
59 this at least 3 weeks before the -rc1 release.
80 * Do bug-fix releases every two weeks until X.1.5 or X.1.6 (if necessary).
89 ----------------------------
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
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.
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 ---------------------
276 Backport Requests
277 -----------------
282 ---------------------------------
289 https://github.com/llvm/llvm-project/issues?q=is%3Aissue+milestone%3A%22LLVM+14.0.5+Release%22+no%3Aproject+
300 its status to "Needs Pull Request", and create a pull request for the fix
301 using the /cherry-pick or /branch comments if this has not been done already.
303 #. If a bug has been fixed and has a pull request created for backporting it,
313 issue's status to "Needs Merge". Check the pull request associated with the
314 issue. If all the tests pass, then the pull request can be merged. If not,
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``.
326 -------------------
356 -------------------
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.