What made you choose Rust 1.67.0?

[steveklabnik]

I don't think this is a bad thing or a good thing, inherently, but I couldn't find any documentation on why this version was chosen, and I think knowing the why would be interesting!

[zanchey]

The widestring_suffix proc macro needed it, but we've dropped that, so could possibly look at lowering it.

[steveklabnik]

Honestly, I am surprised by how low it is, not suggesting you should drop any lower!

maybe a good rephrase is, "is there any criteria you all are using for minimum rust versions?" I know some projects choose things like "latest stable - 3", others would choose something like "the version in current debian stable."

[zanchey]

Sorry, the error I thought was from Corrosion was actually from Cargo.

Workspace inheritance requires 1.64
std::backtrace and let-else needs 1.65
char::methods::::from_u32 and the panic!() macro, as well as some of the pattern matching we use, needs 1.66

1.67 was the latest stable when the RIIR branch was merged. I don't think we'll bump it unless it really benefits us; see @faho's comment here which I concur with: #9944 (comment)

[faho]

is there any criteria you all are using for minimum rust versions?

Just simply "what we need". We would go higher if there's a compelling reason for it, and so far we haven't had a lot.

E.g. like zanchey linked we could have increased MSRV for is_terminal, but then I saw that it literally just calls isatty on unix (and we're not interested in windows), so there's no real point to it.

Basically: We're used to the pain of not requiring C++14 in 2021 because that would be too odious for old systems, by comparison rust 1.67 is nothing. (we have a few lint-allows we could remove and some small backports for is_some_and and friends)

And there would be value in making it build with e.g. Debian's distro rustc (currently 1.63, next is 1.70) if we can achieve that - this isn't for rust nerds but geared towards classic unix types.

I know some projects choose things like "latest stable - 3", others would choose something like "the version in current debian stable."

I'm really not a friend of just automatically bumping the version. Our policy is close-ish to "current debian stable", except we started with 1.67 so we're at the next debian stable right now.

Also I'm okay with bumping it past that if there is a compelling need. We're pretty new to this and so it's not clear to me how workable tying to current debian stable is.

So I guess you could summarize it as "be modest, let's see if we can get by with what's in Debian Stable", basically

[steveklabnik]

Thanks! Appreciate the context.

[krobelus]

debian stable has had a C++20 compiler for a while now, I think one of the problems was systems like centos 7

[faho]

We've increased the MSRV to 1.70 now because no distro ships 1.67, 1.68 or 1.69.

So it wasn't useful to stay there and we didn't have the appetite to decrease the MSRV to Debian Stable's 1.63. 1.70 is the next Debian Stable tho.