Swift 2.2 Release Process(英文)

05 Jan 2016

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 of Xcode.

Logistics

Impacted Repositories

The following repositories will have a swift-2.2-branch to track sources as part of Swift 2.2 release:

• swift
• swift-llvm
• swift-clang
• swift-lldb
• swift-cmark

Schedule

• 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.

Getting Changes into Swift 2.2

• 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.

Release Management

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.

Pull Requests

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 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 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 into swift-2.2-branch.