Winit: Minimum Supported Rust Version

[Lokathor]

Back in https://github.com/rust-windowing/winit/issues/531 it seems that it was agreed to test against 1.24 in CI, and now travis and appveyor just test against stable.

It would be better for the long term health of the community if foundational crates such as winit had a particular version number for minimum rust requirement. Could we move winit back in that direction? Since everyone is working on winit-0.20 being a "big change" with event loop 2.0 and all that, it'd be nice to also use that as a time to transition back to a policy of having a specific minimum rust version and trying to be aware of when that minimum version goes up.

[goddessfreya]

Personally, it is of my opinion that we should support the last three stable rust versions, so 1.36, 1.35 and 1.34 currently. This was discussed between me and @chrisduerr in the past, but I never got around to updating the CI or the readme. I'm not really in favor of a MSRV.

[Lokathor]

I've since had some additional information brought to my attention

• https://github.com/rust-windowing/winit/issues/743
• https://github.com/rust-windowing/winit/pull/746
• https://gitlab.redox-os.org/redox-os/stb_truetype-rs/issues/20

Now, I'm not asking that you always keep the same minimum rust version if your dependencies aren't willing to play along. However, it should be entirely possible for you at least go back to tracking a minimum version and then having any minimum version bumps force a breaking change version bump in your own release.

[chrisduerr]

Personally, it is of my opinion that we should support the last three stable rust versions, so 1.36, 1.35 and 1.34 currently. This was discussed between me and @chrisduerr in the past, but I never got around to updating the CI or the readme. I'm not really in favor of a MSRV.

I think this would be a great idea and offer quite a bit of room for users and distributions to update their systems. Note that I've proposed this policy based on a discussion with alexcrichton here. So winit wouldn't be first to adopt this policy.

I'd also like to note that this doesn't mean that winit can't support older versions, just that changing the minimum version to something older than the last three versions is not a breaking change.

This is an important detail to make maintenance and CI a bit easier. There's no need to bump winit's minimum supported CI version whenever a new Rust version is released, the CI can just stay on 1.20.0 for example but as soon as a change is required which updates to something that was not introduced in the last two rust versions, CI can just be bumped and everything's good again.

This policy would also mean that if there's really a necessity to update to something even more recent, that would be possible too. However, in that case it needs to clearly be marked as a breaking change so no downstream dependencies run into any issues. However I think generally this policy should be lax enough that this shouldn't usually be necessary, but it's an important tool to have to clearly communicate when this is the case.

[Lokathor]

Well, code actually breaks. It worked one moment and doesn't after a cargo update.

That doesn't mean that you can't ever move your minimum rust version, just also reflect it as a breaking change in your version numbering.

[Osspial]

We've gone through this before. I'm extremely wary about doing this without official support from Cargo (such as with https://github.com/rust-lang/rfcs/pull/2495), since it's pretty much impossible to enforce a MSRV if you have dependencies that don't enforce it.

However, it should be entirely possible for you at least go back to tracking a minimum version and then having any minimum version bumps force a breaking change version bump in your own release.

Since we have dependencies that don't enforce a MSRV, this isn't feasible. If you have dependencies that are willing to bump the MSRV in patch releases (which we do), this sort of policy can and will lead to scenarios where breaking changes happen upon running cargo update, even if no changes are made in our repository (see #743, which @Lokathor already linked). It seems awfully arbitrary to force a version bump on our end, especially given that in this scenario any pre-version-bump versions on crates.io are still going to be broken on old versions of the Rust compiler.

I'm not in theory opposed to doing this, but I don't expect it to be feasible without broader coordination in the Rust community. Until then, I have no interest in putting up with the headache that this induces.

[chrisduerr]

it's pretty much impossible to enforce a MSRV if you have dependencies that don't enforce it.

I guess binaries have it a little easier than libraries here, since lockfiles prevent dependencies from getting updated automatically downstream.

However if the library is built sufficient times and people are willing to report issues related to this, cargo is capable of fixing any issues related to this and locking down breaking dependencies temporarily is possible. To make sure this doesn't break releases it would be necessary to always specify fixed dependency versions though, which would likely cause lots of trouble downstream too with having to deal with outdated dependencies.

The reason why I personally requested a minimum supported Rust version to be specified was because winit actually broke things though. And I think that it would definitely be possible to at least track winit's minimum Rust version requirements. At the end of the day, breaking stuff because others do it isn't really a great argument, so that might at least be a good middle ground until proper support is added in cargo (which I'd expect to take at least a couple of years).

@Osspial What do you think about at least having an internal guarantee about winit not breaking stuff like accepting PRs requiring features from the latest stable right after it was released? That should be a good way to at least show that the desire for a little bit of consistency is there and might potentially inspire others to follow suite (and eventually bring around proper cargo support)?

[Lokathor]

If the winit team is interested in moving in this direction but doesn't feel that they have the person-hours needed, I will volunteer to do it.

[chrisduerr]

If the winit team is interested in moving in this direction but doesn't feel that they have the person-hours needed, I will volunteer to do it.

I think the problem isn't necessarily person-hours, but more that it's impossible for libraries to make any guarantees for past releases since the lock file is not provided with libraries.

So any depedency of winit could get updated by a downstream user who still uses winit 0.0.1 which might have coincidentally broken the minimum supported Rust version and the only thing winit could do is yank 0.0.1 and release a new version (probably 0.0.2) which locks down the dependency to a fixed version. This would have to be done for all past releases, which is pretty much impossible to do in practice.

[Lokathor]

Oh, no no, I don't think all winit versions back through time need this. Just moving to this policy going forward, starting with winit-0.20.0 would be satisfactory.

And yes, dependencies doing a min version bump without also doing a breaking release are a problem. My suggestion there would be similar to what you said: temporarily issue a winit patch that holds that dependency back to the last version that worked, and then development going forward can bump the min version, bump the dependency to newest, and then bump the winit version.

[chrisduerr]

Oh, no no, I don't think all winit versions back through time need this. Just moving to this policy going forward, starting with winit-0.20.0 would be satisfactory.

The thing is, all future winit versions would have to be maintained at the same time then. It's just not feasible to yank and push new versions constantly, that'll just create a huge mess.

[Lokathor]

Well, the more you do this, and the more you spread awareness of this to other crates to start playing by the same rules, the easier this process becomes.

I do not think that you can give an absolute guarantee immediately starting in 0.20. That's definitely an unrealistic demand. However, I think that the _intent_ can be broadcast starting with 0.20, and then the situation can become more solid over time.

I don't think that versions would need to be yanked over this until quite far in the future when much more of the ecosystem is on-board with the idea. However, this is a very visible crate to help get the ball rolling with.

[francesca64]

Rather than pushing the burden of this onto every library maintainer in the ecosystem, wouldn't it be better to work on pushing forward the internals discussion on Cargo features, policies, etc. that would enable making these guarantees? You have to persuade a bunch of people either way, and some people will never be convinced unless it's made official.

I've tried playing the "please yank and bump" game before, and it isn't fun. It leads to emotional friction, which leads to me feeling upset and having a bad day. I understand that your goal is to reduce that friction by making Rust version policies a de facto convention, but every maintainer ultimately has their own beliefs and values, and that will lead to many more threads at least as long as this one.

[Osspial]

What do you think about at least having an internal guarantee about winit not breaking stuff like accepting PRs requiring features from the latest stable right after it was released? That should be a good way to at least show that the desire for a little bit of consistency is there and might potentially inspire others to follow suite (and eventually bring around proper cargo support)?

I'm entirely okay with giving the ecosystem a few weeks to catch up to the newest stable version before accepting PRs with new features.

Beyond that, @francesca64's response reflects my views well, and I don't have much more to add at the moment. It'll be much less of headache for everyone involved to defer tackling this until the ecosystem supports it.