Branching and release guidance

Hello Swift Developers,

In the Swift 5.0 timeframe, there was a branch of swift that roughly corresponded with that. The LLVM project has now branched for the 9.0 release but the 5.1 release was cut much earlier (closer to 8.0). I was wondering if the Swift project lead/core team has guidance on how to deal with creating a sync point for clang 9 and swift. Is there going to be another branch that is going to be created soon against the 9.0 release?

This is a general pain point where Swift is not in sync with the LLVM release cycle and branch points which makes it difficult to have a uniform build of clang and LLVM that can be consistently updated. I think that it would be really useful to have a consistent state where the LLVM and Swift projects sync around the release cycle.

CC: @tkremenek @DaveZ

1 Like

The LLVM branches are pretty much arbitrary, and AFAIK it isn't considered best practice for non-LLVM-projects to try to track those branches. We track master, and cut branches from master for llvm and clang at the same time we cut branches for Swift releases.

I don’t think that they are any more arbitrary than the points that the Swift project branches. They release on a regular cadence and backport any critical patches to the branches.

The best practice is to track master, but to do so constantly rather than branching, but Swift doesn’t really do that - it branches at various points.

I think that there is something to be said for branching at the same release points as LLVM which enables a single toolchain that can target the various languages.

Hi @compnerd,

With my ex-Apple hat on and to the best of my memory, the problem with tracking master instead of branching is that it doesn't scale up to institutional sized continuous integration (a.k.a. "daily builds"). Said differently, programmers like to assume that the compiler is reliable because it eliminates an entire dimension of bugs when triaging why a build of an entire operating system is failing.

The net effect is that the compiler needs to be branched periodically and then qualified by rebuilding a known good daily build in what is called a "side build". If the rebuild fails, a compiler engineer then triages why the old compiler worked but the new compiler fails. This approach maximizes the productivity of all involved.

Finally, tracking the upstream release cycle would be worse than what we have today, because Apple's release and qualification cycle isn't synchronized with LLVM's release cycle. With Apple's currently policy, they can branch LLVM's master as late as Apple feels comfortable, thus getting the latest "goodness" into Apple's toolchain. But if Apple felt obligated to align with LLVM's release cycle, then Apple's clang/Swift would probably be months older, if not many months.

Terms of Service

Privacy Policy

Cookie Policy