search

rust-gamedev / wg

Coordination repository of the Game Development Working Group
514 stars 10 forks source link

Gamedev libraries should be encouraged to use Minimum Supported Rust versions #28

Open Lokathor opened 5 years ago

Lokathor commented 5 years ago

At the moment, many libs use "latest stable" as their target Rust.

This is fine for personal projects and even some business projects, but other businesses expect you to pin a compiler the same as you pin all your dependencies. If a library starts using new features and your compiler can't be advanced then that's a breaking change to the library that locks you out of using it. You can't just update your code a bit, you're totally sunk.

I think that it would be good for all of the rust ecosystem to take this more seriously, but since we're the gamedev wg we should attempt to specifically encourage gamedev libs to make this a concern.

The steps for "fixing" this problem are fairly simple:

1) You just change your CI so that entries of stable are replaced with 1.foo.0 for whatever your minimum version is. 2) If you have to bump that version to make the crate build then that's a semver break, and what's worse you just locked some part of the ecosystem out of using your crate, so think hard about it before you do.

How do we know what our minimum rust version is?

I'm so glad you asked. You should open up the rust releases file and have a scan for anything that you're using. Highlights are:

And like, if you need to you can just run it over and over and step around in versions until you find the minimum version to build it. If you're currently targeting "latest stable" without thinking about it then you probably wont have to go too far back to make your build fail.

MaulingMonkey commented 5 years ago

:+1: For game development, this is a particularly strong concern, as you may very well be forking the rust stdlib - which is of course tied to your rust version - to get it to build on your console. Updating the rust version may very well involve merging stdlib changes and writing new platform-specific modifications for your rust stdlib.

Lokathor commented 5 years ago
Lokathor commented 5 years ago

Ah, and there is an RFC for this to become a cargo file attribute:

https://github.com/rust-lang/rfcs/pull/2495

AlexEne commented 5 years ago

As the RFC is being actively discussed I think it's a good opportunity to try and push that forward and collaborate with the owner to get it in a good to merge state, because as it was mentioned in today's meeting, any other option is painful for bigger libraries.

liigo commented 5 years ago

If a library starts using new features and your compiler can't be advanced then that's a breaking change to the library that locks you out of using it.

could you elaborate that, why you can't (or refuse to) upgrade your compiler, which is backward-compatible?

Lokathor commented 5 years ago

Because if you're building for a console target you probably have to use a particular pinned Nightly with no_std and/or a forked stdlib that you've carefully stubbed out just enough stuff to make it build and link and you've got unimplemented! all over and you don't want to just go and upgrade it all every 6 weeks.

This is what the Wii homebrew folks do, this is what the Switch homebrew folks do, and this is what the Chucklefish person did for getting Rust on the official Switch devkit when they were doing that for a while.

Further, even if Rust becomes big enough for a console corp to provide direct Rust support on a console, it's entirely possible that they'll just give you some particular toolchain they've customized in whatever way and then tell you "this is your compiler", and then you just get whatever version you get.

Lokathor commented 4 years ago

Update: an RFC for this to be worked slowly into cargo was merged, tracking issue here: https://github.com/rust-lang/rust/issues/65262