Handle install 6.4-snapshot properly by ktoso · Pull Request #561 · swiftlang/swiftly

ktoso · 2026-06-13T02:47:15Z

swift.org changed the url scheme and 6.4 now needs to become 6.4.x.

We should not require users to know about this and installing 6.4 or 6.4-snapshot is totally expected to work.

This fixes the known urls and also adds a fallback for the future;

Options to consider:

we could remove the fallback... I'm just being extra careful about future i guess, perhaps too much?
we could default all versions from 6.4 onwards to add the .x always, but that's pretty spectulative so i didn't do that.

Current scheme adds the .x for 6.4 and for others it would attempt a fallback to .x but now try it first.

Resolves #560

before:

-> % swiftly install 6.4-snapshot
Fetching the latest 6.4 development branch snapshot...
-----------------------------
A new release of swiftly is available.
Please run `swiftly self-update` to update.
-----------------------------
Error: Unexpected response, expected status code: ok, response: undocumented(statusCode: 404, OpenAPIRuntime.UndocumentedPayload(headerFields: [(field: Server: Apple, next: 65535), (field: Date: Sat, 13 Jun 2026 02:43:54 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 jptyo5-edge-mx-010.ts.apple.com (acdn/316.16515), https/1.1 jptyo5-edge-fx-028.ts.apple.com (acdn/316.16515), next: 65535), (field: X-Cache: hit-stale, miss, next: 65535), (field: CDNUUID: f0997761-ef15-4f9d-ac2e-03889f7307d5-156837625, next: 65535), (field: Connection: keep-alive, next: 65535)], body: Optional(OpenAPIRuntime.HTTPBody)))

after

-> % ./.build/debug/swiftly install 6.4-snapshot
Fetching the latest 6.4 development branch snapshot...
Installing 6.4.x-snapshot-2026-06-10
                                                                                                        Downloading 6.4.x-snapshot-2026-06-10
 2% [====------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------]
Downloaded 42.1 MiB of 1855.3 MiB^C

swift.org changed the url scheme and 6.4 now needs to become 6.4.x. We should not require users to know about this and installing 6.4 or 6.4-snapshot is totally expected to work. This fixes the known urls and also adds a fallback for the future; Options to consider: - we could remove the fallback... I'm just being extra careful about future i guess, perhaps too much? - we could default all versions from 6.4 onwards to add the .x always, but that's pretty spectulative so i didn't do that. Current scheme adds the .x for 6.4 and for others it would attempt a fallback to .x but now try it first.

ktoso

I’ll do some more testing if this doesn’t break anything after the weekend;

ktoso · 2026-06-15T03:44:45Z

+    default:
+        return false
+    }
+}


So here's where we could take a policy decision to just assume future versions follow this .x style or be conservative like it is now and just special case the 6.4... WDYT is better? I guess we'll find out in the future either way heh

Maybe flip it for v >= 6.4 -> true?

So to answer your question, it is expected that the .x will be part of any release development branch, aligning with the branch name on the Swift repository on GitHub, so this can probably be reduced to v >= 6.4.

That said, I wonder if it would make sense to do this in the ToolchainVersion? If it's a snapshot, and the version is 6.4 or newer, the patch version automatically chooses x. Then we don't have to add the additional .release(major, minor, nil) below, and I think we can drop the logic in the catch portion of the getSnapshotToolchains below. The patch string will just return x.

etcwilde

I talked with @shahmishal about this earlier today. The 6.4.x is intentional, specifically so that folks don't expect 6.4.0 when they pull down a 6.4 snapshot from swift.org.
Since Swiftly already gives you the latest, the 6.4.x behavior is already expected.

Since the website is going to start calling the nightlies with .x, but swiftly already makes it apparent that a snapshot is a snapshot in the version selector, I think that it's valuable to accept both.

I think it might be interesting to automatically have the snapshot set the patch to "x" if it's 6.4 or greater and one wasn't specified explicitly. Then we should update the parseReleaseSnapshotWithPatch test to use 6.4 for each, and include a 6.4-snapshot case that should also map to a .release(major: 6, minor: 4, patch: "x") snapshot version to ensure that it's handling the mapping correctly.

etcwilde · 2026-06-18T21:29:53Z

+    default:
+        return false
+    }
+}


So to answer your question, it is expected that the .x will be part of any release development branch, aligning with the branch name on the Swift repository on GitHub, so this can probably be reduced to v >= 6.4.

That said, I wonder if it would make sense to do this in the ToolchainVersion? If it's a snapshot, and the version is 6.4 or newer, the patch version automatically chooses x. Then we don't have to add the additional .release(major, minor, nil) below, and I think we can drop the logic in the catch portion of the getSnapshotToolchains below. The patch string will just return x.

ktoso · 2026-06-19T01:28:28Z

Gotcha, let me rework this a bit then. Bottom line is I think we do want to accept the 6.4-snapshot if the .x was not specified, but we won't do the nil case in the enum but model it with defaulting to the x instead if I understood you correctly. I'll take a stab at it

ktoso · 2026-06-19T07:00:25Z

This ended up much cleaner, please have another look @etcwilde -- thanks!

etcwilde

I like that a lot better. Thanks for making the changes.

I'd like to add verification that 6.4.x-snapshot and 6.4-snapshot evaluate to the same thing, and that 5.7.x-snapshot and 5.7-snapshot don't.

etcwilde · 2026-06-19T20:04:05Z


+    /// From Swift 6.4 onward the swift.org URL scheme uses `X.Y.x`, so a bare
+    /// `6.4-snapshot` (no explicit patch) is normalized to `patch: "x"`.
+    @Test func parseReleaseSnapshotWithoutPatch() throws {


Okay, I think we need to verify that 5.7.x-snapshot and 5.7-snapshot don't evaluate to the same thing and that 6.4-snapshot and 6.4.x-snapshot do.

Since toolchains moving forward will all carry the .x patch, I'm inclined to say that we should take the parseReleaseSnapshot name for the new test verifying the behaviour of 6.4-snapshot and 6.4.x-snapshot, and rename the old test function something liken parseDeprecatedReleaseSnapshot.

Then we merge this with the parseReleaseSnapshotWithPatch test above.

@Test func parseDeprecatedReleaseSnapshot() throws { var parses = [ "5.7-snapshot", "5.7-SNAPSHOT", "5.7-DEVELOPMENT-SNAPSHOT", "swift-5.7-snapshot", "swift-5.7-SNAPSHOT", "swift-5.7-DEVELOPMENT-SNAPSHOT", ] try runTest(.snapshot(branch: .release(major: 5, minor: 7, patch: nil), date: nil), parses) parses = [ "5.7.x-snapshot", "5.7.x-SNAPSHOT", "5.7.x-DEVELOPMENT-SNAPSHOT", "swift-5.7.x-snapshot", "swift-5.7.x-SNAPSHOT", "swift-5.7.x-DEVELOPMENT-SNAPSHOT", ] try runTest(.snapshot(branch: .release(major: 5, minor: 7, patch: "x"), date: nil), parses) } @Test func parseReleaseSnapshot() throws { let parses = [ "6.4-snapshot", "6.4.x-snapshot", "6.4-SNAPSHOT", "6.4.x-SNAPSHOT", "6.4-DEVELOPMENT-SNAPSHOT", "6.4.x-DEVELOPMENT-SNAPSHOT", "swift-6.4-snapshot", "swift-6.4.x-snapshot", "swift-6.4-SNAPSHOT", "swift-6.4.x-SNAPSHOT", "swift-6.4-DEVELOPMENT-SNAPSHOT", "swift-6.4.x-DEVELOPMENT-SNAPSHOT", ] try runTest(.snapshot(branch: .release(major: 6, minor: 4, patch: "x"), date: nil), parses) }

This should cover everything in parseReleaseSnapshot, parseReleaseSnapshotWithPatch and parseReleaseSnapshotWithoutPatch.
Thoughts?

Sure, sounds good -- and I like the having the "deprecated" for the old one, I'll follow up soon

ktoso requested review from cmcgee1024, etcwilde, justice-adams-apple and shahmishal as code owners June 13, 2026 02:47

ktoso commented Jun 13, 2026

View reviewed changes

ktoso commented Jun 15, 2026

View reviewed changes

ktoso mentioned this pull request Jun 17, 2026

swiftly self-update 1.1.1 -> 1.1.2 fails #562

Open

etcwilde mentioned this pull request Jun 18, 2026

Swiftly needs an API for listing valid toolchain names swiftlang/swift-org-website#1452

Open

etcwilde requested changes Jun 18, 2026

View reviewed changes

bring back branch filter

3d290b5

ktoso force-pushed the wip-handle-6.4 branch from ea82923 to ebf2a99 Compare June 19, 2026 06:32

Move the .x normalization into the version itself

70ebf41

ktoso force-pushed the wip-handle-6.4 branch from ebf2a99 to 70ebf41 Compare June 19, 2026 06:59

ktoso requested a review from etcwilde June 19, 2026 06:59

etcwilde reviewed Jun 19, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle install 6.4-snapshot properly#561

Handle install 6.4-snapshot properly#561
ktoso wants to merge 3 commits into
mainfrom
wip-handle-6.4

ktoso commented Jun 13, 2026 •

edited

Loading

Uh oh!

ktoso left a comment

Uh oh!

ktoso Jun 15, 2026 •

edited

Loading

Uh oh!

etcwilde Jun 18, 2026

Uh oh!

etcwilde left a comment

Uh oh!

etcwilde Jun 18, 2026

Uh oh!

ktoso commented Jun 19, 2026

Uh oh!

ktoso commented Jun 19, 2026

Uh oh!

etcwilde left a comment

Uh oh!

etcwilde Jun 19, 2026

Uh oh!

ktoso Jun 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

ktoso commented Jun 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ktoso left a comment

Choose a reason for hiding this comment

Uh oh!

ktoso Jun 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

etcwilde Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

etcwilde left a comment

Choose a reason for hiding this comment

Uh oh!

etcwilde Jun 18, 2026

Choose a reason for hiding this comment

Uh oh!

ktoso commented Jun 19, 2026

Uh oh!

ktoso commented Jun 19, 2026

Uh oh!

etcwilde left a comment

Choose a reason for hiding this comment

Uh oh!

etcwilde Jun 19, 2026

Choose a reason for hiding this comment

Uh oh!

ktoso Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ktoso commented Jun 13, 2026 •

edited

Loading

ktoso Jun 15, 2026 •

edited

Loading