SP-001: Platform Support Levels

[al45tair (Alastair Houghton)]

@0xTim

I agree with the general sentiment above - Linux is too broad to mention for Tier 1, we should be specific and not treat Linux as one platform (i.e. call out what distributions are Tier 1). That opens the door for other distributions to have a path to becoming a tier 1 supported platform, and make it obvious which distributions are only experimentally supported.

Interesting. I had been thinking that the set of distributions was orthogonal to this, and that we would maintain generic Linux support but only build packages for the distributions we test on, with any changes required for other distributions a matter for people packaging Swift for those distributions.

I also worry slightly that this might give the impression that a distribution-maintained package of Swift was somehow unofficial, whereas we'd actually like to get a place where Linux distros can build (and if necessary patch) and package Swift themselves. The only place so far where that has happened is Amazon Linux, but personally I think that's where we'd ideally like to be.

We'll clearly have to talk about this at the Platform Steering Group meeting on Thursday and see what the consensus is.

@0xTim

I’m assuming that Tier 2 includes the requirements from Tier 3 and Tier 1 includes all the requirements from Tier 2 (and Tier 3).

Yes, that is indeed the case:

A Tiered Approach to Platform Support

Swift's platform support strategy employs three distinct tiers, each representing a different level of maturity. The requirements for each tier build upon those of the previous tier.

@0xTim

I also would like to see what exactly are “Swift Core Libraries” - because without a definitive list there are repos and libraries that currently live in a grey area. We should be explicit about what those core libraries are.

We are explicit about it, here:

(See the Swift Runtime Libraries document in the Swift repository for the list of definitions.)

@0xTim

I’m not proposing we introduce strict SLAs but when bugs are discovered, how do we go about getting them fixed. E.g. strict memory checking doesn’t work on Windows. How do we escalate issues like that and ensure they are fixed?

Assuming a Github issue has already been raised, I think the thing to do is to post about it in the forums, pinging the platform owner, and see what they have to say. If you're unhappy with their response, then I'd suggest the next step would be to raise it with @platform-steering-group, and then we'd go and have a conversation with the platform owner to figure out what's going wrong, why things are not being fixed and what we should do about it.

(The tier list is also going to list the platform owners, so you know who to bother.)

@grynspan

We ought to be specific about Apple platforms and Windows too. We don't support Mac OS X 10.4 on PowerPC, obviously. Nor do we support Windows NT on DEC Alpha.

As I said, I think we'll include some indication of the supported triples in the tier list. I don't think it really belongs in this proposal per se.

[0xTim (Tim)]

@al45tair

We are explicit about it, here:

(See the Swift Runtime Libraries document in the Swift repository for the list of definitions.)

So reading that list, Foundation isn’t considered a core library? My understanding was that the Swift standard library encompassed the libraries linked above, where are core libraries are things like Foundation, collections, async-algorithms. And supplemental libraries (point above stands, these should be listed) include things like Swift Log, Swift Metrics, AHC etc. Additionally I’m not sure where things like DocC, the DocC plugin, Swift Syntax etc fall

@al45tair

Yes, that is indeed the case:

Ah apologies, missed that!

[al45tair (Alastair Houghton)]

@0xTim

And supplemental libraries (point above stands, these should be listed)

Those are listed too.

The point here is that these are minimum requirements. You can't be Tier 1 or Tier 2 without them. We're asking people who want their platform to be Tier 1 or Tier 2 to list the libraries they are providing, so that we can take a view as to whether or not the set they propose to support is acceptable.

Importantly we are talking here about Swift runtime libraries and things like Foundation that generally ship with the toolchain, rather than things that are available in packages. Platform support for packages is up to the package maintainers.

[Finagolfin]

@al45tair

we'd actually like to get a place where Linux distros can build (and if necessary patch) and package Swift themselves. The only place so far where that has happened is Amazon Linux

Not true, several distros have included Swift toolchain packages for years, including in the Termux app that runs on Android, ie it's not just "theoretically possible to build a toolchain that runs on Android" like you said above, but I announced it more than five years ago!

[al45tair (Alastair Houghton)]

@Finagolfin

Not true, several distros have included Swift toolchain packages for years,

Interesting. I hadn't realised it was already being packaged in any of the distros. That's certainly something we want to encourage, at any rate.

@Finagolfin

including in the Termux app that runs on Android, ie it's not just "theoretically possible to build a toolchain that runs on Android" like you said above, but I announced it more than five years ago!

Indeed. However, while I know you're keen on it, for a variety of reasons that's not the way most Android developers build their apps, and we wouldn't expect Android to be a Tier 1 Hosted platform as a result.

[0xTim (Tim)]

@al45tair

Importantly we are talking here about Swift runtime libraries and things like Foundation that generally ship with the toolchain, rather than things that are available in packages. Platform support for packages is up to the package maintainers.

Can these be explicitly called out? Because things like Dispatch for instance isn’t listed, but I’m assuming expected. However Dispatch on Wasm doesn’t make sense, so we’d probably want to say that Dispatch is explicitly unavailable for Wasm because it doesn’t make sense for the platform, similar to FoundationInternationalization doesn’t make sense for embedded because it’s too big. IMO those libraries that are part of the toolchain should be called out for clarity.

List of packages I can think of

• FoundationEssentials
• FoundationXML
• FoundationNetworking
• FoundationInternationalization
• Foundation
• Dispatch
• XCTest
• Swift Testing
• Atomics

I don’t think the list of what modules are available with the toolchain is actually listed anywhere

[al45tair (Alastair Houghton)]

@0xTim

Can these be explicitly called out?

I think that's probably a good idea (and thank-you for the helpful list).

[smontgomery (Stuart Montgomery)]

I agree Swift Testing should be on the list. However I think XCTest should not be considered required — or at least, it should have a lower priority/importance than Swift Testing for new platforms going forward. (Perhaps that maps to some lower "tier" level in this policy framework?) Although XCTest is not formally deprecated, Swift Testing is its successor.

[al45tair (Alastair Houghton)]

@smontgomery

I agree Swift Testing should be on the list. However I think XCTest should not be considered required

To be clear, we're talking here about a list of things that are not strictly required but that should be present unless there's a good reason not to.

[grynspan (Jonathan Grynspan)]

@al45tair

To be clear, we're talking here about a list of things that are not strictly required but that should be present unless there's a good reason not to.

Not to toot my own horn, but Swift Testing should almost certainly be required for Tier 1 platforms. I could be convinced it should be optional for Tier 2 though.

[duan (Daniel Duan)]

The cathidral does not simply "support" the bazaar. Many popular Linux distros exist because their users strongly prefer particular ways of software packaging. Swift as it is today makes up a whole bunch of assumptions about the runtime environment that won't work out of the box for any atypcical packaging methods (NixOS/Void Linux come to mind).

A true support claim should include some experiencial statements. Something like "on a tier 1 platform, a user can download the released artifacts from swift.org with the right triple, run swift package ... to ... an executable ... ", "on tier 2 platforms, a user can use swiftc to ...". Or, maybe something for the packagers: "if you have a libc here, and the gold linker there, then congrats, you are supported!" These statements provide real value to users. They'll serve as forcing function to improve the infra of the Swift toolchains.

[al45tair (Alastair Houghton)]

@duan

Swift as it is today makes up a whole bunch of assumptions about the runtime environment that won't work out of the box for any atypcical packaging methods (NixOS/Void Linux come to mind).

I don't want to get into the nitty gritty of what you think we should do differently, because that's off topic, but I will note that we are happy to accept PRs to make Swift easier to package for package maintainers.

[compnerd (Saleem Abdulrasool)]

@0xTim

Atomics

I don't think that Atomics should be in the list as that is not currently part of the SDK: swift-installer-scripts/platforms/Windows/platforms/windows/windows.wxs at main · swiftlang/swift-installer-scripts · GitHub

If this was supposed to be part of the SDK and I missed that discussion, I'd love a pointer so that we can reference that and update the SDK distributions.

[Finagolfin]

Yeah, I don't think Atomics is included with any current platform's toolchain or SDK, but all the rest @0xTim listed usually are.

[0xTim (Tim)]

Ah my bad you’re right it’s not. I think Observation is in there though

[FranzBusch]

I assume @0xTim meant Synchronization which is covered under the Supplemental libraries in the linked doc.

[compnerd (Saleem Abdulrasool)]

Yes, Observation and Synchronization are both part of the SDKs

[3405691582]

Thinking about it some more -- Tier 1 has some clear benefits, namely, that they are collectively "protected". Tier 2 and 3 don't apparently really have a clear benefit for nomination other than to have a point of contact for a platform owner. It would be worthwhile if there was some more discussion as to why one would want to go through the process of nominating a platform for a support tier and what benefits would be reaped from that process. I suppose it would be meaningful for someone who wants to use or build code for a platform to have some understanding of what they might expect for a platform, perhaps?

[al45tair (Alastair Houghton)]

@3405691582

I suppose it would be meaningful for someone who wants to use or build code for a platform to have some understanding of what they might expect for a platform, perhaps?

Yes, that's exactly right. The tiers are primarily there to signal to users of Swift what they can expect of a particular platform.

They also, as you say, have some other impacts like altering the responsibilities of the community and the platform owner, but the main purpose is still to inform users and the alterations are there to make sure that we have confidence that e.g. a Tier 1 platform will have a robust implementation of Swift.

[duan (Daniel Duan)]

No need for nitty gritty. The claim of "tier 1 Linux support" will go like this:

"Tier 1? Cool, I use Linux, time to try Swift!"
...downloads Swift...
...does not work.

"Linux" is too broad to mean anything. And by claiming it's tier 1 supported, the tier system will cease to benefit future expansion of Linux support. I could imagine a future announcement "SOME_DISTRO is getting Tier 1+ like Ubuntu and Amazon Linux!" where the existing "tier 1" is meaningless.

The claim should be more narrow in some way, I can think of 2 ways, either way would be better:

1. Just say Amazon/Ubuntu is tier one support, other Linux distro are supported at a lower tier
2. Say Linux kernel with some runtime requirements (kernel version, libc, etc) has tier 1 support.

In the future when the entire stack can become static executable that basically covers all modern kernels (maybe a wasm executable with a bundled runtime? who knows!), then make a really impressive claim that matches reality.