Skip to content

upgrade to rust 1.85 #3216

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

awol2005ex
Copy link

upgrade to rust 1.85

@blinxen
Copy link

blinxen commented Mar 30, 2025

Changing the MSRV to 1.85, without a good reason, will make bat fail to build on distros that don't have the latest rust version. Example: epel9, epel10 and probably many more.

@Enselic
Copy link
Collaborator

Enselic commented Apr 5, 2025

Why not use rustup to get easy access to the latest Rust version?

@blinxen
Copy link

blinxen commented Apr 5, 2025

For private or development use, that is indeed a good solution. However for stable Linux distributions (e.g. debian, RHEL, Ubuntu) the Rust toolchain is updated in longer cycles. In those cases, if the MSRV is set to a higher version then bat can't be built for them. As the package maintainer of bat for Fedora and EPEL, I would like to keep bat up-to-date there.

@Enselic
Copy link
Collaborator

Enselic commented Apr 5, 2025

Why is not bat also updated in longer cycles in that case? Users of such distros by definition value stability over bleeding edge, don't they?

The reason I am asking these questions is because there is a cost (both in time and in "fun factor") of keeping MSRV low. So I hope we can find a pragmatic approach.

@blinxen
Copy link

blinxen commented Apr 5, 2025

Why is not bat also updated in longer cycles in that case? Users of such distros by definition value stability over bleeding edge, don't they?

I actually do that but there are some corner cases that could break the build. Sometimes a new distribution release gets branched before a Rust update and you get stuck with an old Rust version until the next big release. This makes it not possible to update bat for quite some time. While there are enough workarounds, I would like to always stick to upstream and introduce as little changes when packaging as possible.

The reason I am asking these questions is because there is a cost (both in time and in "fun factor") of keeping MSRV low. So I hope we can find a pragmatic approach.

I am 100% with you on this. You should not forcibly keep the MSRV low, just don't update it if you don't have to. Sometimes a dependency forces you to raise the MSRV because that dependency requires a new language feature. Maybe you guys are the ones that want to use new language features. These are all valid reasons. I just wanted to shed some light on why raising the MSRV without a valid reason could be bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants