The Static SDK for Linux already puts us in this position to a large extent.
But, to be clear, this document is talking about the process. The fact that it states that Linux is on the list of things we consider Tier 1 is really rather a minor part of it, and as I've explained above there will be additional information on the tier list when it's published. It certainly doesn't make sense to have to update a process document every time we change the set of distros that are supported, but it does make sense to indicate that we consider Linux support (in a general sense) to be non-optional, which is what we're doing by saying it's in Tier 1.
I agree. I used Fedora as my primary workstation for a long time, and using Swift there was often painfulâtoolchain builds were unreliable, and I ended up spending a significant amount of time debugging the toolchain build process itself.
That list reflected what was consistently green in CI at the time of writing. Fedora wasnât included because, as I understand it, Fedoraâs release/lifecycle cadence (major updates every ~6 months and support for ~13 months) doesnât align well with a longer development and support cycle like Swiftâs.
I also think we should explicitly clarify architecture support (e.g., x86_64 and arm64) in the same way other languages and frameworks do.
I've not tried it so I could be very wrong here. But the docs for Static SDK states that a working Swift toolchain is a prerequisite. If being a cross compile target makes the platform higher tier, this document should say so.
But, to be clear, this document is talking about the process . The fact that it states that Linux is on the list of things we consider Tier 1 is really rather a minor part of it, and as I've explained above there will be additional information on the tier list when it's published.
If the list is minor part, maybe we should leave it out, and consider it seriously elsewhere?
The full elaboration of the contents of the list which you all are asking for now are a minor part, but the broad list is important, as it indicates that Darwin, linux, and Windows have been grandfathered in as Tier 1 for the heretofore supported triples.
Unlike Swift, Rust typically doesnât need to break down its prebuilt toolchain/SDK by Linux distribution. Swiftâs SDK and runtime librariesâespecially things like Foundationâoften depend on a set of host libraries (e.g., libxml2, ICU), plus additional dependencies for LLDB (including Python itself). Rust, in contrast, largely relies on libc and otherwise ships a mostly self-contained toolchain.
Depending on libc does mean a prebuilt Rust toolchain may not run on very old distributions, but in practice itâs far easier to handle âmany Linux distrosâ with Rust than with Swiftâs current dependency surface.
Foundation, at least on Windows (and the Android SDK on Windows), statically links the dependencies. As a result, on Windows, system dependencies are the C/C++ runtimes and a python installation for LLDB. @JDevlieghere has been making some progress towards letting Python float to any 3.x version, so we should be able to reduce the specificity there. In the mean time, @c_zablit has helped get a python version packaged, so the 6.3 release onwards should only really depend on the C/C++ runtimes from the host.
Exactly right (we intentionally don't use the term "grandfathered" though, as that has a rather unfortunate history).
To re-state the position again, the point of the list in this document is not to enumerate exactly what we support. That information will be elsewhere, and we certainly intend to explicitly list the supported distributions and architectures there. The point here is just to make clear that we recognise that the existing supported platforms are special, and for that purpose it's perfectly reasonable to use the more generic terms.
Adding a little background: some years ago I put myself as maintainer of the Swift toolchain in NixOS. Then I changed employer and had to stop contributing to that project. Because I'm still on the maintainer list, over time I witnessed constant breakages due to upstream infra changes, and heroic efforts from a very small community to fix them. These people like Swift so much they literally make it work without a "normal" system layout for runtime libraries for every Swift release.
The first stated goal of this document is
To establish common terminology and definitions for platform support.
So if tier 1 platform support as defined by this document results in what the Nixpkgs/NixOS community experiences, and not better, the definitions just seem a little silly. All is takes to fix it is to not make a claim so grand.
That's my personal opinion. Sorry for the inconvenience.
I maintain the Android toolchain package and have never seen that level of problems, so this sounds particular to NixOS's more stringent environment and larger set of target platforms.
Hopefully the recent work to revamp the runtimes build system will help reduce that burden. I think that we have already seen the impact of that work in easing cross-compilation and granting better control of the layout.
Sure, I have never submitted that Android toolchain to be officially supported, including going back to my discussion with some core team members years ago about making the Android SDK official, long predating this new policy document on making platforms official.
On the other hand, if I push a commit that breaks the Android toolchain build in CI, I get a sternly-worded letter from other stakeholders and am expected to resolve the breakage. Android is not currently Tier 1 but it is de facto officially supported in some capacity, so in this new scheme it would be Tier something.
And technically, there is no Android toolchain build in any CI: we only build and distribute a Swift SDK For Android, which is expected to be used with the open-source linux or macOS Swift toolchains.
As for Android's official support tier, we have been discussing this off and on with the core team for years now and finally put in our official application last month to the PSG, which is what Alastair is referring to. The swiftlang CI we do have already are in support of that work, and we hope to be at Tier 1 as a SDK at some point this year, though we do not tick all the boxes in this document yet.
I realise this is woolly, but the point is that at Tier 2 you don't have an automatic right to block changes or revert them, but instead the platform owner is encouraged to talk to people who land breaking changes and to work with them to land appropriate fixes.
)