Swift 3.0 Release Process

May 6, 2016

Ted Kremenek

This post describes the goals, release process, and estimated schedule for Swift 3.0.

Swift 3.0 is a major release that is not source-compatible with Swift 2.2. It contains fundamental changes to the language and Swift Standard Library. A comprehensive list of implemented changes for Swift 3.0 can be found on the Swift evolution site.

Swift 3.0 is also the first release to include the Swift Package Manager. While the Swift Package Manager is still early in its development, it supports the development and distribution of cross-platform Swift packages. The Swift Package Manager will be available on both Darwin and Linux.

For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries.

Swift 3.0 is expected to be released sometime in late 2016. In addition to its Swift.org release, Swift 3.0 will ship in a future version of Xcode.

Developer Previews

• Swift 3.0 will have a series of developer previews (i.e., “seeds” or “betas”) that provide qualified and converged builds of Swift 3. The goal is to provide users with more stable and qualified Swift binaries that they can download and try out (and file bugs against) instead of just grabbing the latest snapshot of master.

• The cadence between Developer Previews will likely be irregular, but likely every 4-6 weeks. They will be partially driven by the volume of change going into master and how much time is needed to stabilize a developer preview branch.

• Swift 3.0 will be declared “GM” from the last developer preview branch.

• Content going into developer previews will be managed by the appropriate release manager (see below).

Getting Changes into Swift 3.0

Branches

• master: Development of Swift 3.0 happens in master. All changes going in master will be part of the final Swift 3.0 release until the last developer preview branch is created. At that point master tracks development for future Swift releases.

• swift-3.0-preview-<X>-branch: Branches for developer previews will be created from master. All changes to those branches will need to be submitted via pull requests that initiate testing on continuous integration. The release manager for the given repository approves merging a pull request into the developer preview branch.

• swift-3.0-branch: The last developer preview branch created from master will be called swift-3.0-branch. This will be the final “release branch”.

Philosophy on Taking Changes into Swift 3.0

• As Swift 3.0 converges only changes that align with the core goals of the release will be considered.

• Source-breaking changes to the language will be considered on a case-by-case basis.

• All language and API changes for Swift 3.0 will go through the Swift Evolution process.

• Criteria — as set by the release manager — for accepting changes will becoming increasingly restrictive over time as the release converges. The same policy applies to developer preview branches, which are essentially mini-releases.

Schedule

• The first developer preview branch swift-3.0-preview-1-branch will be created from master on May 12. It will be released 4-6 weeks later.

• The date for creating the last developer preview branch — swift-3.0-branch — has not yet been established. When that date is determined the plan will be communicated both on swift-dev and by updating this post.

Impacted Repositories

The following repositories will have swift-3.0-preview-<X>-branch/swift-3.0-branch branches to track sources as part of Swift 3.0 release:

• swift
• swift-lldb
• swift-cmark
• swift-llbuild
• swift-package-manager
• swift-corelibs-libdispatch
• swift-corelibs-foundation
• swift-corelibs-xctest

The following repositories will only have a swift-3.0-branch instead of developer preview branches, as they have already effectively converged:

• swift-llvm
• swift-clang

Release Managers

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 3.0 release as the release converges:

• Ted Kremenek is the overall release manager for Swift 3.0.

• Frédéric Riss is the release manager for swift-llvm and swift-clang.

• Kate Stone is the release manager for swift-lldb.

• Tony Parker is the release manager for swift-corelibs-foundation.

• Daniel Steffen is the release manager for swift-corelibs-libdispatch.

• Mike Ferris is the release manager for swift-corelibs-xctest.

• Rick Ballard is the release manager for swift-package-manager.

Please feel free to email swift-dev or Ted Kremenek directly concerning any questions about the release management process.

Note: Swift mailing lists have been shut down, archived, and replaced with Swift Forums. See the announcement here.

Pull Requests for Developer Previews

All pull requests nominating changes for inclusion in developer preview branches 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.

All change going into developer preview branches must go through pull requests that are accepted by the corresponding release manager.