Fix windows 1.75 workflow #1425
Conversation
|
It might also be a better idea to update the MSRV as we have other dependencies who would also benefit of it. Is there any downside that comes with upgrading the MSRV? |
|
Like @kingosticks says, we always need to be conscious about our user base who are using this as library and not as binary. Backwards compatibility is an asset and the benefits of demanding our users to upgrade their software base need to be strong. That said, it makes it easier to swallow with other big API breakage, like the dealer, because library users would need to do quite some refactoring anyway. |
|
So if we would do an MSRV bump. How high do you usually bump the version? I would prepare a separate PR with the updates so that we don't have to merge this workaround fix. But we could also just merge this fix. From my point of view I would prefer the version bump. Which seems to be a good time as @roderickvd pointed out. |
|
We could use a clear policy. Before we stuck to the Rust that was available with the latest Debian release. That did not work well, because the Rust ecosystem moves much faster than Debian's releases do. In the Rust ecosystem, I've seen diverse MSRV approaches in various extremes:
I'm actually for a more progressive MSRV on the condition that it brings real value beyond syntactic sugar. "Value" is hard to capture, and to me is along the lines of: enabling some feature that is applicable and desirable to the majority of our user base as we know it. Soon we'll also have new Rust edition on our hands. There, I definitely recommend to hold out because that's viral and I would not like to force it on our library users. |
|
Closed as #1428 was merged |
homeupdated their MSRV to 1.81 (https://github.com/rust-lang/cargo/blob/master/crates/home/CHANGELOG.md#0511---2024-12-16)I only updated the CI for windows as it looks like the MSRV is only required for it. I'm open to different approaches to fix the problem, but this seemed like the most straight forward approach.