Linux build broken on 1.28.0

[francesca64]

stb_truetype updated to Rust 2018 (1.31.0), and once again broke our compatibility guarantees with a patch release.

So, we need to revisit the discussion from #698. We can either...

• Pin dependencies to older versions as necessary
• Move forward to 1.31.0

[mitchmindtree]

Oh wow, I'd say we should definitely report this to stb_truetype but just realised they don't have issues enabled for some reason. Edit: Oh, this is probably because the github repo is just a mirror of a gitlab repo.

@alexheretic I hope you don't mind me pinging you, I just wanted to notify you in case you're unaware of the downstream breakage.

As for the question at hand, I'm always so torn about this. Part of me wants to pin to assert stability, the other part of me wants to allow for the correct usage of semver so that users can get bug fixes and small non-breaking patches without having to wait for winit to manually bump tiny versions of dependencies.

Maybe we can just pin in special cases (like this case) until the next breaking version of winit is ready for release?

As for moving forward to 1.31.0, I personally don't mind, though it would be nice if it could at least wait until the next breaking winit release.

[alexheretic]

Hey guys, I'm sorry to be a cause of some pain here! I only maintain stable compiler compatibility when updating my crates. So it's update both or neither. For std_truetype I would just pin to an older version if that meets your needs.

1.31 is a big release though, I updated all my crates to 2018 for future releases. Perhaps other developers have too, in which case it may be prudent to move winit itself to >=1.31 for the next release.

Also see https://gitlab.redox-os.org/redox-os/stb_truetype-rs/issues/20

[Osspial]

If we're just going to bump the minimum rust version every time a dependency breaks compatibility with an old version of Rust, does it make sense to even provide a minimum version guarantee? I'd argue that it's more effort than it's worth, and I haven't seen anyone outside of the Winit maintainers complain that Winit doesn't work on old versions of rustc. We may want to stop providing guarantees for now, and revisit the topic if RFC 2495 goes through.

[francesca64]

I'm honestly in favor of not providing a minimum version guarantee. Without something like that RFC, it's not practical to keep one, and any guarantee we make can be easily retroactively broken. Besides that, Rust is still evolving a lot, and not being able to take advantage of new improvements is annoying (and can end up being an obstacle for contributors).