Simplifying the apple/llvm-project branches

In order to reduce the complexity and number of branches in apple/llvm-project , we propose to remove the distinction between branches with and without swift-lldb content. Doing so will cut the number of branches and automergers in half. The distinction was originally introduced to make sure merge conflicts in LLDB wouldn’t block LLVM development, but data form the past year has shown it is not as big of a concern as originally thought.

The core idea of this proposal consists of folding the branches with a swift/ prefix into their non-swift counterpart and dropping the apple/ prefix. The apple/main branch will be renamed to next to align with Swift’s next branch and avoid confusion with Swift’s main branch. Please see the graph below for what this will look like.

Note that there won’t be a swift/main branch anymore. Swift's main branch will be aligned directly with the stable/YYYYMMDD branch. Rather than having to remember which branches are aligned between the llvm-project and swift repository, we want to rely on automation such as update-checkout (and a new script to open a Github PR in the browser) to know which branch to work on. We realize this might be a disruptive change but after long consideration we believe relying on automation here is the right trade-off.

Barring any major objections form the community we plan to enact these changes on July 21st. We will merge the branches, rename them and update the CI configuration as well as the documentation.

3 Likes

What'll be the distinction between a stable/YYYYMMDD branch and its corresponding swift/release/X branch in the new scheme?

The arrows from the swift/release/X branch to the stable/YYYYMMDD branch don't indicate merging direction, right? I believe we currently merge the stable branches into the release branches, not the other way around.

It does indicate that the release branch is merged into the stable branch. This matches what happens today, where the swift/release/5.5 branch merges into swift/main.

This is different from the Swift repository, where there is no merge from 5.5 into main, but rather changes are cherrypicked from main (where the majority of development happens) to the release branch. The reason this is different is because clang and lldb either work either on the current release (which is main until swift/release/X is cut) or upstream (until the next rebranch).

The apple/main branch will be renamed to next to align with Swift’s next branch and avoid confusion with Swift’s main branch.

Do you mean that apple/main will merge with swift/next and turn into next?

Roughly:

$ cd llvm-project
$ git checkout swift/next
$ git merge apple/main
$ git checkout -b next

And this also means that the stable cut will be done differently. It seems that it'll need to be cut from the llvm-project:next branch?

And Shoaib mentioned to me that the rebranch will be a monthly occurrence at this point? How will that work?

Basically, or we can drop apple/main and rename swift/next to next. The result should be the same.

Yes, the branch name will change from swift/next to next.

That's what we're aiming for and this proposal is prerequisite to make that work. The idea is that instead of focussing our efforts on keeping next (a moving target) building and passing CI, we branch from next once per month (a fixed target) which gives us one month to qualify the past 30 days of change. If we're happy with the result, we rebranch, and if not we roll over to the next month.

I'll put together a more detailed post about this in the coming days.

Terms of Service

Privacy Policy

Cookie Policy