This post describes the goals, release process, and estimated schedule
for Swift 2.2.
Swift 2.2 is the first offical release of Swift after Swift was
released as open source. It will be a mostly source-compatible
release with Swift 2.1, containing a large number of core improvements
(e.g., bug fixes, enhancements to diagnostics, faster generated code)
without many significant visible changes to the language itself. It
is intended to be an intermediate point between Swift 2 and Swift 3,
with Swift 3 containing more disruptive changes to both the language
and Standard Library.
Swift on Linux will be included in this release. However it is still
relatively new and has known caveats. Swift 2.2 will not include the
Swift Core Libraries but will include LLDB and the REPL.
The Swift Package Manager is still early in development and
will not be included in this release.
In addition to its Swift.org release, Swift 2.2 will ship in a future version
The following repositories will have a
swift-2.2-branch to track sources as part of
Swift 2.2 release:
Swift 2.2 will branch from
masteron January 13, 2016. After
January 13 the
masterbranch will primarily track Swift 3
development. This specifically applies to the swift, swift-lldb,
and swift-cmark repositories.
swift-2.2-branchbranches for the swift-llvm and
swift-clang repositories were created earlier, from roughly LLVM revision
252576, to provide a longer period of time to stabilize the underlying
LLVM platform. Those repositories will not be re-merging from
The final release date for Swift 2.2 is TBD. The intent is for
Swift 2.2 to undergo a convergence period and will likely be
released sometime in March to May of 2016.
Binary builds of the Swift 2.2 release branch will be
made available alongside snapshots of Swift’s
Swift 3 will follow a similar branching process as Swift 2.2 and
will be announced a future date.
Getting Changes into Swift 2.2
Before January 13 all changes going into Swift’s
definition will be a part of Swift 2.2.
Afterwards, the only language/API changes that will be considered
for Swift 2.2 after the branch will be ones that make it more source
compatible with Swift 2.1 or migration warnings for code that will
be a build error in Swift 3. New features/extensions will not be
accepted unless there is a really good reason to take them.
Criteria (as set by the release manager) for accepting changes will
becoming increasingly restrictive over time as the release
Contributions to the
swift-2.2-branchfor those without direct
commit access can be initiated via a pull request.
Pull requests should usually be used to pull in changes that are
masterunless those changes are specific to Swift 2.2
and will not be included in Swift 3. For example, a bug fix should
first land in
masterand then pulled into
Core contributors with direct commit access will be able to directly
cherry-pick or otherwise apply changes to
the guidance of the respective code owner or release manager until a
point in the schedule where the branch is under strict change
control. An announcement will be made to the relevant component
development mailing list (e.g., swift-dev) once the
swift-2.2-branchis under stricter change management. At that
point all changes must go through a nomination process via a
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 2.2 release as the release converges:
Ted Kremenek is the overall release
manager for Swift 2.2.
Bob Wilson is the release manager
for the LLVM and Clang components of Swift 2.2.
Kate Stone is the
release manager for the LLDB component of Swift 2.2.
Please feel free to email swift-dev or Ted directly concerning any
questions about the release management process.
All pull requests nominating changes for inclusion in the
swift-2.2-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
Scope: An assessement 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
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
Prior to the
swift-2.2-branch going into restrictive change
control (as announced by the release manager) a code owner is allowed
to directly accept a pull request after it has gone through the
aforementioned technical review. Once restrictive change control is
in place, only the release manager is allowed to accept a pull request