Swift.org – Swift 5.0 Release Process

September 25, 2018

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

Motivation and Goals

The primary goal of Swift 5.0 is for the language to
achieve ABI stability. This will enable a stable Swift
runtime to be deployed by OS vendors that can be linked against by executables
and libraries.

Related to ABI stability, module stability
will be a primary focal point as well. This will
land in either the Swift 5.0 release or in a subsequent 5.x release
depending on its readiness.

Binary Compatibility

Swift 5.0 is not binary compatible with earlier Swift releases. Binary
compatibility allows Swift code compiled by different Swift compilers to
link together and interoperate at a runtime level.

However, future Swift releases will be binary compatible with Swift 5.

Source Compatibility

As with Swift 4.2, the vast majority of sources that built with the Swift 4.2
compiler should compile with the Swift 5.0 compiler.

However, the Swift 3 compatibility mode will not be supported in the Swift 5
compiler. Swift 4.2 is the last release of Swift to support Swift 3 mode.
There are important changes to both the surface of the language and the
interior of its implementation in the releases following Swift 3 that will be
the basis of future (and lasting) source and binary stability.

Snapshots of Swift 5.0

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

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

Getting Changes into Swift 5.0

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

• The swift-5.0-branch has already been initially cut from master.

• Periodically, the master development branch will be merged into
  swift-5.0-branch until the final branch date.

• November 16, 2018 (final branching): The swift-5.0-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).

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

Philosophy on Taking Changes into Swift 5.0

• All language and API changes for Swift 5.0 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-5.0-branch branch to track
sources as part of Swift 5.0 release:

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

Please feel free to post on the development forum
or contact 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 after the final re-branch from master 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-5.0-branch (outside changes being merged
in automatically from master) must go through pull requests that are
accepted by the corresponding release manager.