This post describes the goals, release process, and estimated schedule for Swift 2.2.
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.
Swift 2.2 will branch from master on January 13, 2016. After January 13 the master branch will primarily track Swift 3 development. This specifically applies to the swift, swift-lldb, and swift-cmark repositories.
The swift-2.2-branch branches 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 master.
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 master development branch.
Swift 3 will follow a similar branching process as Swift 2.2 and will be announced a future date.
Before January 13 all changes going into Swift's master branch 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-branch for 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 master unless 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 master and then pulled into swift-2.2-branch.
Core contributors with direct commit access will be able to directly cherry-pick or otherwise apply changes to swift-2.2-branch under 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-branch is under stricter change management. At that point all changes must go through a nomination process via a pull request.
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.
Scope: An assessement of the impact/importance of the change. For example, is the change a source-breaking language change, etc.
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 into swift-2.2-branch.