Swift 3.1 Release Process

December 9, 2016

Ted Kremenek

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

Swift 3.1 is intended to be source compatible with Swift 3.0. It will contain a few additive enhancements to the core language as well as improvements to the Swift Package Manager, Swift on Linux, and general quality improvements to the compiler and Standard Library.

Swift 3.1 is intended to be released in the spring of 2017.

Source Compatibility

It is a strong goal that the vast majority of sources that built with the Swift 3.0 compiler continue to build with the Swift 3.1 compiler. The exception will be bug fixes to the compiler that cause it to reject code that should never have been accepted in the first place. These cases should be relatively rare in practice.

A description of the intent for source compatibility for Swift releases can be found on a thread on the swift-evolution mailing list.

Please file bug reports if you encounter cases where the Swift 3.1 compiler unexpectedly rejects code that previously compiled with the Swift 3.0 compiler.

Snapshots of Swift 3.1

Previous releases of Swift have had “Developer Previews”, e.g. “Preview 1”, “Preview 2”, etc., that represent stabilized snapshots of a Swift release as it converges. Developer previews have often been irregularly spaced apart, and have sometimes not provided enough granularity for the Swift community to try out new features or verify bug fixes in a release as it converges.

For Swift 3.1 there will instead be daily downloadable snapshots of the release branch. Snapshots will be produced as part of continuous integration testing. The cadence of downloadable snapshots will thus be more frequent and granular. Snapshots will be posted daily, assuming tests are passing.

Once Swift 3.1 is released, official final builds will also be posted in addition to the snapshots.

Getting Changes into Swift 3.1

Swift 3.1 is intended to be limited in scope, with the desire to move focus early in 2017 to the development of Swift 4. To meet this goal, Swift 3.1 will include changes in mainline development (i.e. the master branch) only until January 16. After that date there will be a “bake” period in which only select, critical fixes will go into the swift-3.1-branch and move master on to Swift 4 development.

Branches

master: With the exception of the swift-llvm and swift-clang repositories (see Impacted Repositories), development of Swift 3.1 happens in master. All changes going in master will be part of the final Swift 3.1 release until January 16. At that point master tracks development for Swift 4.
swift-3.1-branch: Release management for Swift 3.1 happens on the swift-3.1-branch. All Swift 3.1 snapshots are built from this branch, and Swift 3.1 will GM from this branch as well.

Operationally, master will be regularly merged into swift-3.1-branch approximately every two weeks until January 16. The two week window provides a buffer between hot development on master and a curated release branch. Changes may be cherry-picked (via pull requests) into swift-3.1-branch between merges of master.

A notable exception to this plan is the swift-package-manager, which will merge from master into the swift-3.1-branch daily.

Philosophy on Taking Changes into Swift 3.1

Source compatibility with Swift 3.0 is a top priority.
As Swift 3.1 converges only changes that align with the core goals of the release will be considered.
All language and API changes for Swift 3.1 will go through the Swift Evolution process.
Major work for Swift 3.1 should orient around the January 16 date, but changes can still land in 3.1 afterwards per the judgement of the release manager. As the release converges, the criteria for pulling changes into 3.1 will become increasingly restrictive.

Impacted Repositories

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

Note that the swift-llvm and swift-clang repositories have already branched swift-3.1-branch from master and will not rebranch again.

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

Ted Kremenek is the overall release manager for Swift 3.1.
Frédéric Riss is the release manager for swift-llvm and swift-clang.
Jason Gosnell 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.
Brian Croom 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 Release Branch

All pull requests nominating changes for inclusion in the release 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.

All change going into the swift-3.1-branch (outside changes being merged in automatically from master) must go through pull requests that are accepted by the corresponding release manager.