Swift 3.1 gives source compatibility a release process

A source-compatibility promise needs a process for deciding which changes enter a release. A compiler can reject an old program because a bug was fixed, while a library update can break the same program without any new language syntax. Swift 3.1's release plan makes those cases part of release management. The project wants a limited update that preserves Swift 3 code while allowing development to turn toward Swift 4.

Ted Kremenek's December 9 release-process announcement targets spring 2017. The stated scope includes additive language improvements, work on Swift Package Manager and Linux, and compiler and standard-library quality. These are plans for an upcoming release. The announcement does not establish a final release date or claim that every intended change is complete.

I like Swift's language design, but the time spent building a small application is already an unwelcome cost. A compiler update that also requires source repairs makes that cost harder to accept. The useful part of this plan is its explicit treatment of existing programs as a constraint on release decisions.

Compatibility has a direction

The intended rule is that the vast majority of code accepted by Swift 3.0 should continue to build with Swift 3.1. The announcement allows exceptions for compiler fixes that reject code the compiler should never have accepted. It asks users to report unexpected rejections, which makes an old program failing under the new compiler evidence of a possible regression.

Ewa Matejska's November discussion of source compatibility, linked by the release plan, explains an asymmetry that matters for package authors. Swift 3.x aims to accept Swift 3 programs without modification. A program using a new additive feature in a later 3.x compiler need not compile with the original Swift 3 compiler. Compatibility preserves existing inputs without promising that older tools understand newly introduced constructs.

That distinction affects dependency choices. A package can keep working for existing clients when they update their compiler, yet start requiring a newer compiler after its own source adopts a new feature. Those are separate decisions. Calling a compiler release source compatible does not mean every package written for that release is usable with every older compiler in the series.

The discussion also describes the proposed Swift 4 compatibility modes. A compiler flag would select Swift 3 or Swift 4 language behavior, with each module using one mode. Modules in different modes could interoperate in one binary. As of this announcement, that is the intended migration design for Swift 4, not a compatibility flag needed to use Swift 3.1.

A branch separates development from convergence

The release plan keeps Swift 3.1 development on master until January 16. After that cutoff, master moves to Swift 4 development and the release branch enters a period reserved for selected critical fixes. This gives contributors a date for substantial work while preserving a separate place to stabilize the release.

Before the cutoff, the plan calls for merging master into swift-3.1-branch approximately every two weeks. Changes can also reach the release branch through individual pull requests between those merges. The interval deliberately puts some distance between ongoing development and the branch used to produce release snapshots. It is a buffer for selecting and integrating changes, not a claim that every mainline commit is immediately suitable for release.

Swift Package Manager has a different cadence, with daily merges into its release branch. The LLVM and Clang repositories have already branched and will not branch again. These exceptions matter because Swift's release is assembled across multiple repositories. A branch policy for the compiler alone cannot describe the state of the package manager, debugger or core libraries.

Snapshots make compatibility observable

Previous developer previews have appeared at irregular intervals. Kremenek explains that the gaps have sometimes made it difficult for the community to try changes or verify repairs as a release converges. Swift 3.1 will instead provide daily downloadable release-branch snapshots when continuous-integration tests pass. Official final builds will still be published when the release is complete.

More frequent artifacts reduce the interval between a change entering the release branch and an outside user being able to try it. They also let a bug reporter distinguish the toolchain that exhibited a problem from a later toolchain containing a proposed fix. That is a practical benefit of the publishing cadence even when the application's own source remains unchanged.

I value this part of the plan because source compatibility has to be checked against actual programs. A policy can describe the intended outcome, but downloadable toolchains let package maintainers expose counterexamples while there is still time to repair the release branch.

Release decisions need specific evidence

The plan requires a release-branch nomination to explain the change, assess its scope and identify its particular risk. It also asks for the related issue when applicable and a description of testing performed or still needed. Code owners review the affected components, and the corresponding release manager must accept changes outside the scheduled automatic merges.

This makes the narrowing acceptance criteria operational. A useful change is not automatically a suitable late release change. Its compatibility consequences and validation must support taking it into a branch whose purpose has shifted toward convergence. Language and API changes still go through Swift Evolution, so release management does not replace design review.

The compatibility discussion extends the same reasoning to Apple SDK imports. It notes that an SDK change previously required migration even without language changes, and proposes a stricter compatibility expectation for Swift 3.x and Swift 4's Swift 3 mode. Version-sensitive API notes can preserve the older imported view of an evolving SDK. That addresses a concrete source of compiler-upgrade breakage outside the parser and type checker, where the declarations visible to a program can change underneath otherwise unchanged Swift source.