No longer try to support ancient Rust versions. #74
Conversation
|
@thomwiggers Very good point! |
|
Seems the merge queue doesn't care about resolved conversations and approval, by the way |
|
Merge queues make my head hurt! |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
We've kept around support for pre-Rust-1.37 for long enough: it's unlikely that anyone using a pre-Aug-2019 rustc will be brave/foolish enough to update Vob, or any other crate, any more!
ltratt
force-pushed
the
bit_reverse_has_been_stable_for_long_enough
branch
from
44c967c to
ff6a713
Compare
|
Ah, |
|
#76 duplicates that but okay |
|
Dumb question: should this lead to a major release, or are we comfortable with this being a minor release? I think minor releases fairly frequently break "this works on old rustc" but I'm unsure whether that's technically "in the spirit of the semver rules" or not. |
|
I think projects that are more explicit about MSRV do do semver breaks when they change the minimum rustc required; I don't think this project ever made such claims (Certainly, we don't seem to have the metadata). See e.g. rust-random/rand@c1f865f |
|
I think that it is generally considered maintainer judgement, in that there is nothing holding anyone to a specific compiler version. Like you can specify updating the minimum supported rust version is a breaking change as a guarantee that you commit to as maintainer, but unless you do that there is nothing to hold you to it. |
|
Thanks both. I think a minor release seems most appropriate then. |
We've kept around support for pre-Rust-1.37 for long enough: it's unlikely that anyone using a pre-Aug-2019 rustc will be brave/foolish enough to update Vob, or any other crate, any more!
[Spotted in #73, because the Cargo syntax has changed, so if we wanted to keep this hack going forwards, we'd need to have another conditional for newer rustc versions. That doesn't really seem worth the complexity.]