-
Notifications
You must be signed in to change notification settings - Fork 30
Creating a new release branch
Bryan Chan edited this page Mar 19, 2024
·
5 revisions
- Check out the most newly created stable release tag from upstream llvm-project, e.g.
llvmorg-18.1.0
, into a suitably named branch, e.g.release_18x
. - List all downstream GitHub workflow changes in the current release branch, committed since the upstream stable tag, e.g.
Cherry-pick these workflow changes into the new branch.
git log --oneline llvmorg-17.0.2..origin/release_17x | grep workflows
- Push the new branch to GitHub. Then invoke the "Pre-compile llvm ARM64" action manually to initialize the Docker container needed to test Classic Flang on AArch64, by visiting the action page linked above, and clicking "Run workflow". Don't forget to select the new branch (i.e.
release_18x
) and check the "True if creating an initial Docker image for this branch" checkbox. - When the action has completed successfully, submit a pull request that targets the new branch, to cherry-pick the remaining downstream patches from the current release branch on to the new branch. Try to keep the commit history intact, especially for more recent changes; for older commits, it may be necessary to squash them to avoid excessive merge conflicts. If you do squash commits, it is advised to keep the message text of those commits in the squashed commit. Some examples are commits cb0096558aa6 and 22499392fe13.
- Before the pull request can be merged, it should pass all tests and be approved by all reviewers as usual. Some example PRs are #159 and #166. After it is merged successfully, change the default branch in the project settings to point to the new release branch.