Swift 6.4 Release Process

Development Announcements
1

Swift 6.4 Release Process

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

Snapshots of Swift 6.4

Downloadable snapshots of the Swift 6.4 release branch will be posted regularly as part of continuous integration testing. As support is available, snapshot downloads will be added for newly supported platforms.

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

Getting Changes into Swift 6.4

On May 4th, 2026 the release/6.4.x branch will be cut from main in the swift repository and related project repositories. This will contain the changes that will be released in Swift 6.4. After the branch is cut, changes can be landed on the branch via pull request if they meet the criteria for the release.

:warning: Until the new branch is created on May 4, 2026, the main branch should be treated as a release branch. Major changes should be avoided during this time, and the focus should be on converging the release. This approach will allow us to branch later and minimize the overhead of cherry-picking changes into the release branch early on.

Philosophy on Taking Changes into Swift 6.4

  • All language and API changes for Swift 6.4 will go through the Swift Evolution process. Evolution proposals should aim to be completed by the branch date in order to increase their chances of impacting the Swift 6.4 release. Exceptions will be considered on a case-by-case basis, particularly if they tie in with the core goal of the release.
  • 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 release/6.4.x branch to track
sources as part of Swift 6.4 release:

The llvm-project will have a corresponding swift/release/6.4.x branch from stable/21.x.

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

Platform Release Managers

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 (release/6.4.x ) after it has been cut, the pull request must have:

  • A title starting with a designation containing the release version number of the target branch.
  • This form filled out in its description. An item that is not applicable may be left blank or completed with an indication thereof, but must not be omitted altogether.

To switch to this template when drafting a pull request in a swiftlang repository in a browser, append the template=release.md query parameter to the current URL and refresh. For example:

-https://github.com/swiftlang/swift/compare/main...my-branch?quick_pull=1
+https://github.com/swiftlang/swift/compare/main...my-branch?quick_pull=1&template=release.md

All changes going on the release/6.4.x branch must go through pull requests that are accepted by the corresponding release manager.

9 Likes
Possible miscompiles in OptimizeHopToExecutor
2

@mishal_shah Could you add swift-tools-protocols to the branching repos? It's now branch-based since [update-checkout] Use swift-tools-protocols:main instead of a tag by rintaro · Pull Request #87886 · swiftlang/swift · GitHub

1 Like
3

The main branch is now in convergence, which means major changes, such as large refactoring or new features, should be avoided. This strategy is intended to maintain the stability of the Swift 6.4 release leading up to the May 4th branch. For any work that requires broad changes or introduces new features, create a feature branch and open a draft pull request. All updates to the swiftlang/swift repository’s main branch require approval from the release managers. A pull request targeting swiftlang/swift will automatically add release managers. You can also contact them via @release-managers in the forum group.

4

In order for a pull request to be considered for the main branch, the pull request must have the release nomination form filled out in its description. We’re also updating the pull request template to include this form and make it easier to find. If the pull request isn’t ready for review by release managers, please keep it in draft. We are also extending the release managers’ approval. The complete list of repositories is swiftlang/swift , swiftlang/llvm-project , swiftlang/swift-driver , and swiftlang/swift-syntax .

Needs:

  • A completed release nomination form that explains the fixes and the intended for this release.
  • A technical review by a code owner.
  • Final approval by a branch manager after tests have passed and code owner review is completed.

Examples:

  • Bug fixes should be made when the fix is low risk or when the bug has a high impact.
    • For instance, most improvements to diagnostics are usually low risk.
    • A miscompile can have serious consequences, so fixes with moderate risk may be appropriate. For example, rejecting the code that causes a miscompile and triggers a compiler error may be justified, even if some valid code no longer compiles.
    • Even if a bug fix meets these criteria, try to keep the changes as limited as possible.
  • You can also work on implementing Swift Evolution proposals that have been accepted or are currently being reviewed by the steering group.
    • Make changes behind an experimental flag only with clear guidance from a steering group.

If your pull request is not intended for merging before the branch date, please keep it in draft until after the Swift 6.4 branch is created.

3 Likes
5

@mishal_shah Quick question from a new contributor about reviewer assignment under convergence. I just merged my first PR and have a few more planned.

With .github/CODEOWNERS now routing everything to @swiftlang/swift-branch-managers, new PRs no longer auto-request the subsystem reviewers who would typically do the initial technical review. Since I don't have write access to request reviewers manually, my plan is to tag the relevant subsystem owners from the pre-convergence .github/CODEOWNERS in a PR comment asking for review. Is that the right approach, or is there a preferred workflow for new/external contributors under the current setup?

Related: Will .github/CODEOWNERS return to its prior per-path mapping after the 6.4 branch is cut on May 4th, or is this the ongoing state for main between releases going forward? This affects whether it makes sense to just hold non-urgent PRs until after the branch cut.

Thanks!

6

Yes, this is correct approach. Unfortunately, GitHub tooling does not support model we are using currently.

Yes, it will return back after we cut the branch on May 4th.

3 Likes
7

We have created branches for Swift 6.4.x (release/6.4.x), and the main branch no longer requires approval from the @release-managers to merge changes.

3 Likes