This post describes the goals, release process, and estimated schedule for
Motivation and Goals
Swift 4.2 is meant to be a waypoint towards achieving ABI stability in Swift
Swift 4.2 will include numerous under-the-hood ABI changes as part of the
effort to stabilize the Swift ABI. It is
valuable to incrementally roll out ABI changes — many of which are performance
related — to provide ample time for user feedback in assessing these changes
before they are locked into the final ABI.
Swift 4.2 will also include numerous bug fixes, as well as have a goal of some
focused improvements on compile-time performance.
Swift 4.2 is not binary compatible with previous Swift releases.
As with Swift 4.1, the vast majority of sources that built with the Swift 4.0
compiler (including those using the Swift 3 compatibility mode) should compile
with the Swift 4.2 compiler.
There will be some exceptional cases where this cannot be an absolute
guarantee. This includes fixes to incorrect behavior in the compiler or
corner cases with the uses of generics now addressed by the introduction of
long-anticipated generics features. The expectation, however, is that most
projects will continue to build with no source changes.
Snapshots of Swift 4.2
Downloadable snapshots of the Swift 4.2 release branch will be posted
regularly as part of continuous integration testing.
Once Swift 4.2 is released, the official final builds will also be posted in
addition to the snapshots.
Getting Changes into Swift 4.2
swift-4.2-branch contains the changes that will be released in Swift
4.2. The branch will be managed as follows:
- Imminently: The
swift-4.2-branchwill be initially cut from
- Approximately every two weeks,
masterwill be merged into
swift-4.2-branchuntil the final branch date.
- April 20, 2018 (final branching): The
changes merged from
masterone last time. After the final branch date
there will be a “bake” period in which only select, critical fixes will go
into the release (via pull requests).
Four notable exceptions to this plan are swift-package-manager, swift-llbuild,
swift-corelibs-foundation, and swift-corelibs-libdispatch which
will merge from
swift-4.2-branch daily and whose final cutoff
date for changes will extend beyond April 20 and will be announced later.
Philosophy on Taking Changes into Swift 4.2
All language and API changes for Swift 4.2 will go through the Swift
Evolution process, with criteria
for what changes are in scope for the release documented there.
Other changes (e.g., bug fixes, diagnostic improvements, SourceKit interface
improvements) will be accepted based on their risk and impact.
Low-risk test tweaks will also be accepted late into the release branch if
it aids in the qualification of the release.
As the release converges, the criteria for accepted changes will become
The following repositories will have a
swift-4.2-branch branch to track
sources as part of Swift 4.2 release:
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:
Pull Requests for Release Branch
In order for a pull request to be considered for inclusion in the release
branch it must 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
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?
Reviewer: 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
All change going into the
swift-4.2-branch (outside changes being merged
in automatically from
master) must go through pull requests that are
accepted by the corresponding release manager.