Swift.org – Swift 4 Release Process

February 16, 2017

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

Swift 4 is a major release that is intended to be completed in the fall of 2017. It pivots around providing source stability for Swift 3 code while implementing essential feature work needed to achieve binary stability in the language.
It will contain significant enhancements to the core language and Standard Library, especially in the generics system and a revamp of the String type. More details can be found on the Swift Evolution page.

Source Compatibility

The Swift 4 compiler will provide two language modes: -swift-version 3 and -swift-version 4.

Swift Version 3 Mode

The first mode, -swift-version 3, is the default for existing code. Under this mode, it is a strong goal that the vast majority of sources that built with the Swift 3.1 compiler continue to build with the Swift 4 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.

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

Swift Version 4 Mode

The second mode, -swift-version 4, is the mode that makes available the new and disruptive changes in the release. Of notable importance is an overhaul of the String API, where a key focus is to improve the ergonomics of the API and its performance. These changes are source-breaking, and thus will require existing code to migrate to using the new APIs.

It is worth noting that, from a code migration perspective, the difference between Swift 3 and Swift 4 code is expected to be much smaller than the jump from Swift 2.2 to Swift 3.

Mixing Code with Different Language Modes

The intended design is that a project containing multiple Swift modules, such as an Xcode project with multiple Swift targets, will be able to adopt into the specific Swift language mode on a per module (target) level and that they can freely interact within the same compiled binary. Note that this interoperability only exists at the binary level when the targets are compiled with the same compiler.

Here are some examples of what this interoperability enables:

• In Xcode, an application target can be writen in Swift 4 (i.e., -swift-version 4) but the project can have a separate framework target used by the application that is written in Swift 3 (i.e., -swift-version 3).

• A Swift package written in Swift 4 (i.e., -swift-version 4) should be able to use existing packages that are written in Swift 3 without needing the packages to update their source code to Swift 4.

Overall, this scheme will allow existing Swift 3 code to more gradually migrate to Swift 4 (e.g., a target or package at a time).

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

Snapshots of Swift 4

As in the case of Swift 3.1, for Swift 4 there will 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 4 is released, official final builds will also be posted in addition to the snapshots.

Getting Changes into Swift 4

All changes currently going into mainline development (i.e. the master branch) until a final branch date is announced by the release manager, which will likely be sometime in early summer of 2017. After that point there will be a “bake” period in which only select, critical fixes will go into the swift-4.0-branch and move master on to developement for the next release.

Branches

• master: With the exception of the swift-llvm, swift-clang, and swift-lldb repositories (see Impacted Repositories), development of Swift 4 happens in master. All changes going in master will be part of the final Swift 4 release until the final branch date. At that point master tracks development for the next release.

• swift-4.0-branch: Release management for Swift 4 happens on the swift-4.0-branch. All Swift 4 snapshots are built from this branch, and Swift 4 will GM from this branch as well.

Operationally, master will be regularly merged into swift-4.0-branch approximately every two weeks until the final branch date. 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-4.0-branch between merges of master.

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

Philosophy on Taking Changes into Swift 4

• Source compatibility with Swift 3.1 is a top priority in -swift-version 3 mode.

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

• All language and API changes for Swift 4 will go through the Swift Evolution process, with criteria for what changes are in scope for the release documented there.

• As the release converges, the criteria for pulling changes into 4 will become increasingly restrictive.

Impacted Repositories

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

Note that the swift-llvm, swift-clang, and swift-lldb repositories have already branched swift-4.0-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 4 release as the release converges:

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

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-4.0-branch (outside changes being merged in automatically from master) must go through pull requests that are accepted by the corresponding release manager.