search

rust-lang / hashbrown

Rust port of Google's SwissTable hash map
https://rust-lang.github.io/hashbrown
Apache License 2.0
2.46k stars 288 forks source link

`hashbrown` 0.15.1 bumped the MSRV on a patch release #585

Open tnull opened 3 weeks ago

tnull commented 3 weeks ago

We are users of hashbrown, directly as well as through other dependencies over which are out of our control (notably, indexmap). Unfortunately, yanking hashbrown 0.15.0 and releasing 0.15.1 also bumped the MSRV in that patch release, which renders it incompatible with our MSRV of 1.63.

As some of our dependencies had already upgraded to 0.15 (and hence require 0.15.x as a minimum version), we can't simply pin hashbrown back to a compliant MSRV. I'd therefore like to ask whether you could reconsider bumping the MSRV on a patch release. And, if really necessary, at least make it a minor release or at least a separate patch release so that we have options left.

Thank you, it would be highly appreciated!

tnull commented 3 weeks ago

Also want to note that it seems a minor release was previously planned for this: https://github.com/rust-lang/hashbrown/pull/570#issuecomment-2406017398

Amanieu commented 3 weeks ago

I've unyanked 0.15.0 so you should be able to use the same approach as #572 to test your MSRV by using -Z direct-minimal-versions.

However moving forward there will likely be continued increases to the MSRV, even on patch releases. It's just not reasonable to expect crates to forever support a 2 year old compiler. If you are using an old compiler then you should also be using older versions of crates.

TheBlueMatt commented 3 weeks ago

So what is the MSRV policy? Based on that comment it sounds like it's "sorry, you deal with it, we're not gonna think about it".

In general I'm somewhat surprised you find it challenging to maintain a consistent MSRV on patch releases. Sure, sometimes issues crop up, but when only applying bugfixes maintaining an MSRV seems to be a minuscule level of work, even for bigger projects (eg tokio), at least if you exclude dependencies randomly breaking shit.

clarfonthey commented 3 weeks ago

The MSRV policy is that we are okay bumping two versions up when the MSRV is already substantially older than we would be willing to keep it at. We're not going to bump to the latest stable on a patch release, and as discussed in #571, it's probably going to be kept at least a full year behind stable.

The reality is that there are two MSRVs: an absolute limit we won't pass (if we go with a full year behind, that is around 1.74) and the actual MSRV based upon the code we've written. Once we've decided on that absolute limit and the code is actually closer to surpassing that limit, then we will probably adopt a policy of not bumping it on patch releases.

This was a special case because the change was unexpected and we're not even close to getting to the MSRV limit we want to be at.

TheBlueMatt commented 3 weeks ago

Is it possible to provide an MSRV for past release patch versions? I realize this is talking about the latest version (which I missed above) where development wants to move forward and use new features, but for past releases where we're really just talking about backported bugfixes, presumably the overhead of maintaining MSRV is much, much lower.

cuviper commented 3 weeks ago

I don't know that hashbrown has ever done a maintenance update on older releases, but I think it's reasonable to say that those should not bump MSRV, if they do happen.