Rust support across macOS and Windows versions

[XAMPPRocky]

Currently we support the following targets for Windows & macOS. An issue that has crept more over time is that the specific OS versions that were initially put for support, are no longer tested and built by Rust. This is for a variety of reasons, the main one being that we are bound by the OS versions provided by our CI providers.

platform	OS
i686-apple-darwin	32-bit OSX (10.7+, Lion+)
i686-pc-windows-gnu	32-bit MinGW (Windows 7+)
i686-pc-windows-msvc	32-bit MSVC (Windows 7+)
x86_64-apple-darwin	64-bit OSX (10.7+, Lion+)
x86_64-pc-windows-gnu	64-bit MinGW (Windows 7+)
x86_64-pc-windows-msvc	64-bit MSVC (Windows 7+)

Potential Solutions

• Update Rust's target guarentees to the latest releases.
• Update our platform targets to be OS aware.
  • Not sure how effective this would be as currently Apple and Microsoft have two completely different release schemes. Apple annually releases OS's with breaking changes, and Microsoft will likely not publish a new numbered version of Windows any time in the near future.

[cuviper]

• Update Rust's target guarantees to the latest releases.

Or at least limit ourselves to vendor-supported releases, although that doesn't solve the CI issue.

[XAMPPRocky]

Update Rust's target guarentees to the latest releases.

One thing I forgot to include about this point is this is technically a breaking change. We did break it for 32-bit because there is no vendor or CI support. Upgrading the latest releases for these platforms would be more of an issue as there are not current versions that do have vendor support and significant users. Namely the previous two Apple releases, and Windows 7.

[pietroalbini]

I don't have an opinion on which versions we want to support, but (with my release hat) I strongly think we should commit to something, and actively test that we're still supporting it.

It can be "We test Windows 7 onwards", or "We test the latest 3 macOS releases", or a different policy for each target, but we need to commit to it.

[XAMPPRocky]

@pietroalbini I agree with that, however given the CI situation (at least as I understand it) we'd be more likely to say we support Windows 10 and onwards, which might be a more controversial change.

[pietroalbini]

I agree with that, however given the CI situation (at least as I understand it) we'd be more likely to say we support Windows 10 and onwards, which might be a more controversial change.

But that's what we're guaranteeing in practice today. Yeah, we're probably going to fix a Windows 7 bug if people report it, but we still don't run the tests on that platform ourselves (which is a requirement for being tier 1, both in the current understanding and in the RFC draft).

[cuviper]

One thing I forgot to include about this point is this is technically a breaking change.

I think we need a better definition of breaking change here, because it's not reasonable to expect that we'll continue supporting a given OS forever, especially when its vendor doesn't.

[XAMPPRocky]

I agree. I do think there's merit in supporting an older platform if there's a significant enough community built around it, even if the vendor chooses not to support it. I don't think that's the case here though.

[Centril]

So I think that the terminology "breaking change" here wrt. targets is quite different than the lang/libs sense of RFC 1122 and API evolution. It's fundamentally less permanent and more best effort (e.g. based on CI, vendor support, time, etc.) due to the issues @cuviper brings up.

I also think that the support policy can be per-target or per-OS like what @pietroalbini suggested. That seems quite sensible due to differing levels of support from each OS/platform.

(That said, I don't have specific expertise wrt. macOS to offer, so I'll keep my comments to general policy.)

[Mark-Simulacrum]

I don't have an opinion on which versions we want to support, but (with my release hat) I strongly think we should commit to something, and actively test that we're still supporting it.

But that's what we're guaranteeing in practice today. Yeah, we're probably going to fix a Windows 7 bug if people report it, but we still don't run the tests on that platform ourselves (which is a requirement for being tier 1, both in the current understanding and in the RFC draft).

I don't personally see that it is necessarily true that what we guarantee and what we test need to coincide. That seems like an extremely high bar, too high for our purposes! I think we should document what we currently test on CI, and what we intend to support beyond that (i.e., where we will dedicate developer time, prioritize bugs, etc.). I think that making it mandatory that anything we claim to support is fully tested on CI is too high a bar; it would unduly limit the support structure we can give. I suppose in some sense this means that only what we test on CI is a Tier 1 platform per I believe current definitions (tests + builds available) whereas previous platforms are Tier 2 (builds available, tests not run).

For example, with macOS, it is my impression that testing anything except the latest release is not really super tenable with our current and future CI providers. But I would expect us to still support (say) the last three releases of macOS; we would not test that support explicitly, but any reported bugs would be prioritized as if it was the latest release of macOS. I don't know how far back we would go (maybe three releases, like what Apple does it seems).

[BatmanAoD]

@Mark-Simulacrum This seems to point to a longer discussion we should perhaps have. Our tier guarantees are defined primarily in terms of CI, so it seems to me that there may be some value in brainstorming a way to maintain some kind of relationship there. One idea I just had is rotating which version of a given platform we test with for every test cycle, so that we're still using the same amount of compute resources to do a single test run, but over time we'd catch regressions on specific versions.

[Mark-Simulacrum]

AIUI, it's not a resourcing problem -- we literally don't have CI providers that support macOS 10.13, for example.

[pietroalbini]

Hmm, ok, given the discussion I'd be fine with not testing everything on CI. With my release hat I'm not happy about it, but with my infra hat I don't know how to actually test on every platform without setting up custom CI infra.

[XAMPPRocky]

Okay, how do we communicate this change? Is this something that needs to be part of the Target Tier Policy RFC, its own RFC, or just an update to the forge documentation?

[Mark-Simulacrum]

To be clear, I believe that the change we are considering is changing the minimum OS X version to 10.13 (from 10.7), which falls in line with Apple support (per rust-lang/rust#50776 (comment)).

I believe that we should prepare an RFC, similar to @pietroalbini's 32-bit Apple demotion to tier 3 RFC, and aim to land that. The RFC would be slightly different in that it would set a minimum bar that on Apple, we support no earlier than latest publicly security-release targeted versions by the vendor (only Apple, in this case). As of today, that's 10.13.

[XAMPPRocky]

@Mark-Simulacrum What about Windows? We have the same problem with Windows 7/8, where we don't have machines to test with.

[Mark-Simulacrum]

Ah, looks like Windows 7 is also EOL (https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information) so we can include stripping it per the same reasoning. I don't think we should do the same for Windows 8.1, as it looks like extended support extends into 2023 for that.

We may not have machines, but this policy is also not about that. As we've discussed on this thread, these support tiers are mostly about "we will do our best to support this target" vs. "we will close/ignore bugs found" -- or so is my interpretation. Obviously, if we don't have available machines, it's highly likely bugs will get fixed very slowly, if at all, but they at least won't get closed out of hand.

[vrubleg]

@Mark-Simulacrum Windows 7 has Extended Security Updates for companies till 2023:
https://support.microsoft.com/en-us/help/4527878/faq-about-extended-security-updates-for-windows-7

[Mark-Simulacrum]

Good to know! I do still think that Rust probably needs to say that we don't really support Windows 7 because I don't think it's really feasible for anyone on the Rust teams to support it -- we just don't have the ability to install it I imagine.

[vrubleg]

Are you aware that Windows 7 alone is 10+ times more popular than Linux on desktops? It is too early to abandon Windows 7.

[noloader]

I can provide remote access to a PowerMac G5 running OS X 10.5. It is still one of my favorite machines. It runs faster then modern Atoms and Celerons.

I can also provide access to Solaris 11.3 i86pc for testing.

Send your SSH authorizes_keys file to noloader, gmail account. In return's I'll make you an admin on the box and send you the IP to connect.

[noloader]

@Mark-Simulacrum,

Ah, looks like Windows 7 is also EOL (https://www.microsoft.com/en-us/windows/windows-7-end-of-life-support-information) so we can include stripping it per the same reasoning.

Negative. Windows 7 still has a 28% of market share. The market determines when an OS is no longer needed, not a company suffering seller's regret. Microsoft's fiat's mean nothing.

And here's an interesting way to look at it: if you are going to drop support for Windows 7 with a 28% market share, then you should surely drop Linux with a 1.2% market share.

[XAMPPRocky]

@vrubleg @noloader Platform support is not solely a popularity contest and Rust runs on a lot of different kinds of architectures and machines not just desktops so there are more considerations and constraints at play than simply "which has the most people?". There's also a meaningful difference here between being able to build rustc and tooling to run on Windows 7 and being able to build your application with Rust that runs on Windows 7. This is mostly a discussion about the former AFAIU.

[ChrisDenton]

I wrote this topic in the forum while ignorant of this issue.

As far as I understand it, in practice Rust only has full tier 1 support (as currently defined) for Windows 10 1607 and 1809. That is, those are the two that can be tested on Azure. Downgrading Windows 7 to a separate tier would better reflect reality. Or perhaps, as has been suggested, it may be better to change how support is explained.

Of course this shouldn't mean the platform will be abandoned or that bugs wouldn't be fixed. It's just a statement of how things are. rustc developers can still endeavour to avoid making changes that they know will break Windows 7. And if there are enough developers using Windows 7 (and 8.1, etc) there will hopefully be enough to run tests, raise issues and submit PRs in the event that anything does break. This is how things are right now, whatever the policy says.

---

To be clear, the current tier 1 policy is:

Tier 1 platforms can be thought of as "guaranteed to work". Specifically they will each satisfy the following requirements:

• Official binary releases are provided for the platform.
• Automated testing is set up to run tests for the platform.
• Landing changes to the rust-lang/rust repository's master branch is gated on tests passing.
• Documentation for how to use and how to build the platform is available.

As it stands today, Windows 7 only truly fulfils the first and last of those bullet points.

[djc]

Maybe there's also a role here for platform vendors to support the Rust project in maintaining support for older releases? @rylev does MS have thoughts about they might want to handle this going forward?

[rylev]

I think @danielframpton might have a more clear opinion on this. I'll let him answer before I add any of my own (personal) opinions.

[ChrisDenton]

Microsoft will likely not publish a new numbered version of Windows any time in the near future.

Sorry to be nitpicky here but this is only really true in the same sense that MacOS was stuck on version 10 for two decades. New versions of Windows will always be under the "Windows 10" umbrella from now on but that's not relevant in terms of their release scheme.

Microsoft releases a new version of Windows twice a year which are marketed using a year/month scheme. For example, the latest is "2004" aka "April 2020". These releases each have their own support lifetime. Individually each release is much smaller than, for example, the transition from 8.1 to 10 was. However the releases are cumulative so going from 1507 to 2004 could potentially be a very big change (albeit somewhat mitigated by Windows' commitment to backwards compatibility).

All this is to say that when we talk about which platforms are tested it makes more sense to talk specifically about 1607, 1809, etc. In this context saying merely "Windows 10" is not very helpful unless we actually test all 10 versions of Windows 10.

[apiraino]

As an additional bit of data point, we might want to take into account platform data gathered also from the Rust Survey 2019. Perhaps the 2020 survey could break down a bit the Windows platform into 7, 8, 10/1507, 10/2004, ...) to gain insights on what developers are really using/interested in.

[cuviper]

The new target tier policy in RFC 2803 has something to say about all of this. (Thanks @inquisitivecrystal for pointing this out.)

• Note that in some cases, based on the usage of existing targets within the Rust community, Rust developers or a target's maintainers may wish to modify the baseline expectations of a target, or split an existing target into multiple targets with different baseline expectations. A proposal to do so will be treated similarly to the analogous promotion, demotion, or removal of a target, according to this policy, with the same team approvals required.
  • For instance, if an OS version has become obsolete and unsupported, a target for that OS may raise its baseline expectations for OS version (treated as though removing a target corresponding to the older versions), or a target for that OS may split out support for older OS versions into a lower-tier target (treated as though demoting a target corresponding to the older versions, and requiring justification for a new target at a lower tier for the older OS versions).

We still have open questions about CI though, because we simply don't have the means to test all versions from that oldest baseline -- often we only have access to the most current.

[tesaguri]

Windows 8.1 support and Windows 7 Extended Security Updates have ended on January 10, 2023, and no ESU for Windows 8.1 is provided (reference).

[djc]

Right, the plan for Windows target bumps was discussed in MCP 651.