Swift.org – Swift 2.2 Release Process

January 5, 2016

Ted Kremenek is a member of the Swift Core Team and manages the Languages and Runtimes group at Apple.

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:

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.