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.

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

4 Likes
8

No big rush… but was there any estimate when we might have toolchains available from swiftly install 6.4-snapshot?

9

The 6.4 snapshots will be produced by 6.4 CI, which are being set up now after the branch. Last spring, it took a couple weeks from the 6.2 branch till the first snapshot on April 21.

1 Like
10

Just checking on the status of the snapshot toolchains. I see the 6.4.x snapshot tags are getting cut regularly, but I still haven't seen a toolchain produced for any of these on swift.org or via swiftly.

2 Likes
11

Is there anything the community can do to help unblock the snapshots? Are there any good first issue tasks that a volunteer could help work on?

12

I don't know, but I doubt it. Most are already available on swift.org, it's just a matter of adding the links on the install webpage and so on, once the CI team is ready.

The main issue we always need help with is breaking CI, which falls on the way-overloaded CI team. These three CI "trigger" all the snapshot toolchain builds, so you can look at those individual CI links in the log and see what the problems are then report or help with them:

You will notice that the macOS arm64 CI are currently ignored when tagging snapshots, as are new CI like Ubuntu 26.04 that are still being worked on.

1 Like
13

Apologies for the delay in releasing the nightly toolchain for release/6.4.x. We recently resolved issues with the Windows toolchain build, which had caused the delay. The nightly toolchain should be available by the end of the day.

6 Likes
14

I guess you are aware, but the whole 6.4.x stuff is very much not working with swiftly at the moment.

The instruction on swift.org results in an error

> swiftly install 6.4.x-snapshot
Error: invalid toolchain selector: "6.4.x-snapshot"

And using 6.4-snapshot does not work either:

> swiftly list-available 6.4-snapshot
Error: Unexpected response, expected status code: ok, response: undocumented(statusCode: 404, OpenAPIRuntime.UndocumentedPayload(headerFields: [(field: Server: Apple, next: 65535), (field: Date: Wed, 03 Jun 2026 10:57:05 GMT, next: 65535), (field: Content-Type: text/html, next: 65535), (field: Content-Length: 146, next: 65535), (field: Strict-Transport-Security: max-age=31536000; includeSubdomains, next: 65535), (field: X-Frame-Options: SAMEORIGIN, next: 65535), (field: X-XSS-Protection: 1; mode=block, next: 65535), (field: Age: 2, next: 65535), (field: Via: https/1.1 defra2-xdc-mx-021.ts.apple.com (acdn/302.16436), https/1.1 defra1-edge-fx-022.ts.apple.com (acdn/302.16436), next: 65535), (field: X-Cache: hit-stale, miss, next: 65535), (field: CDNUUID: db278d73-f56a-49ab-93eb-d378f6f2413a-10638219304, next: 65535), (field: Connection: keep-alive, next: 65535)], body: Optional(OpenAPIRuntime.HTTPBody)))

edit:
I just saw @Finagolfin created a github issue as well: The new 6.4 snapshots are unsupported · Issue #548 · swiftlang/swiftly · GitHub

2 Likes
15

This is now resolved in Swiftly 1.1.2 release.

To update swiftly to 1.1.2

swiftly self-update
1 Like
16

is it just me or is the self update not working? (on macOS)

swiftly self-update
Checking for swiftly updates...
Checking for swiftly updates...
A new version of swiftly is available: 1.1.2
                            Downloading swiftly 1.1.2
100% [=============================================================]
Downloaded 9.8 MiB of 9.8 MiB

Extracting the swiftly package...
installer: Error - the package path specified was invalid: '/var/folders/7w/fd5kdmmj5mqd5j5yjznxs5g40000gn/T/swiftly-7E52CA25-3595-4E84-A70E-5CA7EB9593C9'.
Error: RunProgramError(exitCode: 1, program: "installer", arguments: ["-pkg", "/var/folders/7w/fd5kdmmj5mqd5j5yjznxs5g40000gn/T/swiftly-7E52CA25-3595-4E84-A70E-5CA7EB9593C9", "-target", "CurrentUserHomeDirectory"])
1 Like
17

Not working for me either.

1 Like
18

I think this might be the fix?

19

The self update bug was resolved in main and did not make it into 1.1.2 release.

To workaround the issue: Documentation

2 Likes