Swift 4 Release Process

Ted Kremenek Ted Kremenek

This post describes the goals, release process, and estimated schedule for Swift 4.

Swift 4 is a major release that is intended to be completed in the fall of 2017. It pivots around providing source stability for Swift 3 code while implementing essential feature work needed to achieve binary stability in the language. It will contain significant enhancements to the core language and Standard Library, especially in the generics system and a revamp of the String type. More details can be found on the Swift Evolution page.

Source Compatibility

The Swift 4 compiler will provide two language modes: -swift-version 3 and -swift-version 4.

Swift Version 3 Mode

The first mode, -swift-version 3, is the default for existing code. Under this mode, it is a strong goal that the vast majority of sources that built with the Swift 3.1 compiler continue to build with the Swift 4 compiler. The exception will be bug fixes to the compiler that cause it to reject code that should never have been accepted in the first place. These cases should be relatively rare in practice.

Please file bug reports if you encounter cases where the Swift 4 compiler unexpectedly rejects code that previously compiled with the Swift 3.1 compiler.

Swift Version 4 Mode

The second mode, -swift-version 4, is the mode that makes available the new and disruptive changes in the release. Of notable importance is an overhaul of the String API, where a key focus is to improve the ergonomics of the API and its performance. These changes are source-breaking, and thus will require existing code to migrate to using the new APIs.

It is worth noting that, from a code migration perspective, the difference between Swift 3 and Swift 4 code is expected to be much smaller than the jump from Swift 2.2 to Swift 3.

Mixing Code with Different Language Modes

The intended design is that a project containing multiple Swift modules, such as an Xcode project with multiple Swift targets, will be able to adopt into the specific Swift language mode on a per module (target) level and that they can freely interact within the same compiled binary. Note that this interoperability only exists at the binary level when the targets are compiled with the same compiler.

Here are some examples of what this interoperability enables:

Overall, this scheme will allow existing Swift 3 code to more gradually migrate to Swift 4 (e.g., a target or package at a time).

A more detailed description of the intent for source compatibility for Swift releases can be found on a thread on the swift-evolution mailing list.

Snapshots of Swift 4

As in the case of Swift 3.1, for Swift 4 there will be daily downloadable snapshots of the release branch. Snapshots will be produced as part of continuous integration testing. The cadence of downloadable snapshots will thus be more frequent and granular. Snapshots will be posted daily, assuming tests are passing.

Once Swift 4 is released, official final builds will also be posted in addition to the snapshots.

Getting Changes into Swift 4

All changes currently going into mainline development (i.e. the master branch) until a final branch date is announced by the release manager, which will likely be sometime in early summer of 2017. After that point there will be a “bake” period in which only select, critical fixes will go into the swift-4.0-branch and move master on to developement for the next release.

Branches

Operationally, master will be regularly merged into swift-4.0-branch approximately every two weeks until the final branch date. The two-week window provides a buffer between hot development on master and a curated release branch. Changes may be cherry-picked (via pull requests) into swift-4.0-branch between merges of master.

A notable exception to this plan is the swift-package-manager, which will merge from master into the swift-4.0-branch daily.

Philosophy on Taking Changes into Swift 4

Impacted Repositories

The following repositories will have a swift-4.0-branch branch to track sources as part of Swift 4 release:

Note that the swift-llvm, swift-clang, and swift-lldb repositories have already branched swift-4.0-branch from master and will not rebranch again.

Release Managers

The overall management of the release will be overseen by the following individuals, who will announce when stricter control of change goes into effect for the Swift 4 release as the release converges:

Please feel free to email swift-dev or Ted Kremenek directly concerning any questions about the release management process.

Note: Swift mailing lists have been shut down, archived, and replaced with Swift Forums. See the announcement here.

Pull Requests for Release Branch

All pull requests nominating changes for inclusion in the release branch should include the following information:

One or more code owners for the impacted components should review the change. Technical review can be delegated by a code owner or otherwise requested as deemed appropriate or useful.

All change going into the swift-4.0-branch (outside changes being merged in automatically from master) must go through pull requests that are accepted by the corresponding release manager.