| 17 Sep 2025 |
 Randy Eckenrode | I suppose swiftPackages gets renamed to swiftPackages_5? | 01:36:49 |
| Randy Eckenrode | I like this less than just slipping the update to 26.05. | 01:36:59 |
 emily | well, it's like 10 lines of churn to open up the namespace :) | 01:37:27 |
| emily | slipping is okay with me though. once the next -next starts in a day or two I'll take a quick look at if it'll be easy to do an in-place 5.10 bump | 01:37:50 |
| emily | which would solve the SDK thing | 01:37:53 |
| Randy Eckenrode | If it requires more than non-zero work, I’ll do some kind of SDK crime for Swift to keep a 13.3 SDK around for it. | 01:38:17 |
| Randy Eckenrode | I’d rather not waste effort on a Swift 5.10 bump that’s going to be thrown away (especially if the C++ bootstrap path works with Swift 6.2). | 01:38:37 |
| emily | I'd rather just bump SDK/minver to 13 for 25.11 than have a swift dependency be the secret way to get an older SDK than we support | 01:39:15 |
| Randy Eckenrode | It also causes problems for out-of-tree users. swift will start throwing for them and then stop mid-cycle if they support/use stable releases. | 01:39:15 |
| emily | but I already spent like a week or two with the Swift derivation getting rid of llvmPackages_15 so I'm ok burning a day on 5.10 to unblock 14 | 01:39:35 |
| Randy Eckenrode | Swift will build with a private SDK and just roll with whatever SDK you use. The SDK warnings are bullshit IME. | 01:39:46 |
| emily | well, it'll be a breaking change now that they have to accommodate, yeah | 01:39:58 |
| emily | but so would be Swift 6 | 01:40:01 |
| Randy Eckenrode | Swift 6 itself isn’t a breaking update. | 01:40:09 |
| emily | a breaking backport would be worse in that regard | 01:40:14 |
| emily | sure but the Nix side would change | 01:40:18 |
| Randy Eckenrode | True. The Nix side will change because the current situation is hard to maintain and makes packaging Swift apps not great. | 01:40:42 |
| emily | it didn't look like that was going to work from the 10 minutes I spent on it | 01:40:45 |
| emily | sure I'm not saying it's not a good change :) | 01:40:54 |
| emily | I'm just saying in terms of what's breaking / bothersome for users | 01:40:59 |
| Randy Eckenrode | As in the resulting Swift couldn’t build things when using a newer SDK? | 01:41:03 |
| emily | as in the issues with apple-sdk_14 in the Swift build where when it was trying to do swiftc stuff | 01:41:23 |
| emily | and barfing on headers | 01:41:29 |
| Randy Eckenrode | I would have to look at it, but what I’m proposing is using a private 13.3 SDK to build Swift while using the 14.4 SDK to build Swift applications. | 01:41:55 |
| emily | yeah, my impression is that that wouldn't work | 01:43:29 |
| emily | but if it does then cool | 01:43:31 |
| Randy Eckenrode | I would have to see. I won’t be touching Swift until October at the earliest. The Darwin stuff is more important, and my time is pretty limited. | 01:44:28 |
| emily | yeah I'll look briefly at 5.10 in the next few days but if not then meh | 01:45:52 |
| emily | I think bumping to 13.x would be fine enough for 25.11 really | 01:46:05 |
| emily | we're not super obligated to drop support for it if dropping support is more of a pain than keeping it | 01:46:22 |
