Swift 2.2 Release Process
This post describes the goals, release process, and estimated schedule for Swift 2.2.
Swift 2.2 is the first official 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 of Xcode.
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
masterbranch by 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 converges.
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 already in
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
swift-2.2-branchunder 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 pull request.
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 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.
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