Bump required toolchain to Swift 5.10

[lorentey]

This drops support for Swift releases that aren't covered by CI, and it lets us entirely get rid of C-based atomics.

Checklist

• I've read the Contribution Guidelines
• My contributions are licensed under the Swift license.
• I've followed the coding style of the rest of the project.
• I've added tests covering all new code paths my change adds to the project (if appropriate).
• I've verified that my change does not break any existing tests.
• I've updated the documentation if necessary.

[lorentey]

Ah, @retroactive is 6.0-only.

[rgoldberg]

@lorentey Is there anyway you could leave the Swift version at 5.9?

My project must support building on all versions of macOS currently supported by Apple, which includes macOS 13.

Swift 5.10 cannot build on macOS 13. Only Swift 5.9 & older can build on macOS 13.

Thanks for any possible help.

[lorentey]

Our policy is that feature releases of these packages (swift-atomics, swift-collections, swift-algorithms etc) support the last three Swift releases, which are currently 5.10, 6.0 and 6.1. (This is in addition to the two future Swift versions that are currently under active development.)

I really do need to stick to this -- every supported version multiplies the amount of effort it takes to validate the release, and to state the obvious, we aren't exactly rich in resources to spend on this package.

[lorentey]

@rgoldberg Do you have any actual pressing need for any of the pending changes? (A build warning is a cosmetic issue; it is not exactly a blocker. A dependency spec that requires >= 1.2 but also allows 1.3 would solve that just as well.)

Incidentally, disjointed PR comments are perhaps the least productive way to discuss these matters -- we have a dedicated swift-atomics area on the Swift forums. Issues raised there have a much better chance of attracting the attention of folks who have the power of changing things.

[rgoldberg]

@lorentey I was mainly worried that the warning might indicate some actual runtime problems. I also wanted to clean up my build logs. Otherwise, I don't know of any direct need for a new version; I am, however, using main instead of 1.2.0, so maybe, without my explicit knowledge, some of the post 1.2.0 commits are necessary for my app to function properly…

I imagine that you guys won't change from supporting only the 3 most recent stable Swift releases, but, to me, it would be nice if you could support building on the most recent version of all major versions of macOS that are currently supported by Apple (currently 13.x, 14.x & 15.x, which requires Swift 5.9 for 13.x).

Where on the Swift site should I ask about changing this policy?

This helps support contributors for open source projects as it's difficult to mandate the latest macOS versions if someone isn't being paid, and it facilitates distribution via Homebrew formulae, which require a formula to be able to build on the platform to which it is being deployed (I asked the Homebrew team about cross-building on a newer macOS to deploy on older macOS versions; they said they'd accept a good PR that implements it, but they aren't planning on doing it themselves, plus it sounds like it would take nontrivial investigation & work to design, implement, test, etc.)

Thanks for the info.

[lorentey]

I am, however, using main instead of 1.2.0

Please do not do that. The package only promises source compatibility across tagged releases; development branches can be (and often are) unstable, full of known issues, etc. (Thank you for the extra testing, though!)

Where on the Swift site should I ask about changing this policy?

I have linked to the forum area for this package; that is a good start.

I imagine that you guys won't change from supporting only the 3 most recent stable Swift releases, but, to me, it would be nice if you could support building on the most recent version of all major versions of macOS that are currently supported by Apple (currently 13.x, 14.x & 15.x, which requires Swift 5.9 for 13.x).

It's a bit sad, but we really do not have capacity to provide cosmetic fixes for older minor versions -- the number of toolchains to (manually!) test would be quite unreasonable. That said, if we found a severe bug, it is still technically possible to backport fixes onto one or more earlier minor releases. I don't think any of the changes in 1.3 are severe enough to make that effort.

Tagging v1.3 does not remove version 1.2; that version will continue to remain available to folks on 5.9 or below. Their SwiftPM will not try updating them to 1.3 -- they will simply remain on the 1.2 release series, even if their dependency spec would allow the update to 1.3. (For reference, it is still possible to build Swift 5.1 code that depends on swift-atomics -- such code just gets the 1.0 line.)

[rgoldberg]

@lorentey I didn't mean all minor versions, just the most recent release of each major version currently supported by Apple, so just 3 versions of macOS (I wrote .x because I don't know the current latest versions of 13 or 14, nor are the exact current versions important here)

Thanks again for the info.