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.
The Swift 4 compiler will provide two language modes:
-swift-version 3 and
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:
In Xcode, an application target can be writen in Swift 4 (i.e.,
-swift-version 4) but the project can have a separate framework target used by the application that is written in Swift 3 (i.e.,
A Swift package written in Swift 4 (i.e.,
-swift-version 4) should be able to use existing packages that are written in Swift 3 without needing the packages to update their source code to Swift 4.
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.
master: With the exception of the swift-llvm, swift-clang, and swift-lldb repositories (see Impacted Repositories), development of Swift 4 happens in
master. All changes going in
masterwill be part of the final Swift 4 release until the final branch date. At that point
mastertracks development for the next release.
swift-4.0-branch: Release management for Swift 4 happens on the
swift-4.0-branch. All Swift 4 snapshots are built from this branch, and Swift 4 will GM from this branch as well.
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
A notable exception to this plan is the swift-package-manager, which will merge from
master into the
Philosophy on Taking Changes into Swift 4
Source compatibility with Swift 3.1 is a top priority in
As Swift 4 converges only changes that align with the core goals of the release will be considered.
All language and API changes for Swift 4 will go through the Swift Evolution process, with criteria for what changes are in scope for the release documented there.
As the release converges, the criteria for pulling changes into 4 will become increasingly restrictive.
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
master and will not rebranch again.
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:
Ted Kremenek is the overall release manager for Swift 4.
Ben Cohen is the release manager for the Swift Standard Library.
Please feel free to email swift-dev or Ted Kremenek directly concerning any questions about the release management process.
Pull Requests for Release Branch
All pull requests nominating changes for inclusion in the release branch should include the following information:
Explanation: A description of the issue being fixed or enhancement being made. This can be brief, but it should be clear.
Scope: An assessment of the impact/importance of the change. For example, is the change a source-breaking language change, etc.
SR Issue: The SR if the change fixes/implements an issue/enhancement on bugs.swift.org.
Risk: What is the (specific) risk to the release for taking this change?
Testing: What specific testing has been done or needs to be done to further validate any impact of this change?
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.