Swift.org – Swift 4.1 Release Process

October 17, 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.1.

Swift 4.1 is a source compatible update to Swift 4.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 4.1 is not binary compatible with 4.0. It contains a variety of under-the-hood changes that are part of the effort to stabilize the Swift ABI in Swift 5.

Swift 4.1 is intended to be released in the first half of 2018.

Source Compatibility

The vast majority of sources that built with the Swift 4.0 compiler (including those using the Swift 3 compatibility mode) should compile with the Swift 4.1 compiler. There will be some exceptional cases where this cannot be an absolute guarantee. This includes fixes to incorrect behavior in the compiler or corner cases with the uses of generics now addressed by the introduction of long-anticipated generics features. The expectation, however, is that most projects will continue to build with no source changes.

Snapshots of Swift 4.1

Downloadable snapshots of the Swift 4.1 release branch will be posted regularly as part of continuous integration testing.

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

Getting Changes into Swift 4.1

The swift-4.1-branch contains the changes that will be released in Swift 4.1. The branch will be managed as follows:

• October 18, 2017 (initial branching): The swift-4.1-branch will be initially cut from master.
• Approximately every two weeks, master will be merged into swift-4.1-branch until the final branch date.
• December 4, 2017 (final branching): The swift-4.1-branch will have changes merged from master one last time. After the final branch date there will be a “bake” period in which only select, critical fixes will go into the release (via pull requests).

Four notable exceptions to this plan are swift-package-manager, swift-llbuild, swift-corelibs-foundation, and swift-corelibs-libdispatch which will merge from master into swift-4.1-branch daily and whose final cutoff date for changes will extend beyond December 4 and will be announced later.

Philosophy on Taking Changes into Swift 4.1

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

• Other changes (e.g., bug fixes, diagnostic improvements, SourceKit interface improvements) will be accepted based on their risk and impact.

• Low-risk test tweaks will also be accepted late into the release branch if it aids in the qualification of the release.

• As the release converges, the criteria for accepted changes will become increasingly restrictive.

Impacted Repositories

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

The swift-llvm, swift-clang, swift-compiler-rt, and swift-lldb repositories have already branched swift-4.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 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

In order for a pull request to be considered for inclusion in the release branch it must 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?

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