Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[release-0.13.x] Update MSRV to 1.63.0 #487

Closed
wants to merge 4 commits into from
Closed

[release-0.13.x] Update MSRV to 1.63.0 #487

wants to merge 4 commits into from

Conversation

matthiasbeyer
Copy link
Member

Foe the next 0.13.x release, we need a newer MSRV, because the log dependency does not build with 1.59.0 anymore.

So we update the MSRV here.

@matthiasbeyer
Update MSRV to 1.60.0
d97b904 
For the next 0.13.x release, we need a newer MSRV, because the log
dependency does not build with 1.59.0 anymore.

So we update the MSRV here.

Signed-off-by: Matthias Beyer <[email protected]>
@matthiasbeyer matthiasbeyer force-pushed the release-0.13/update-msrv branch from 3e0361c to d97b904 Compare October 23, 2023 17:25
@matthiasbeyer
Update MSRV to 1.61.0
dac422e 
For the next 0.13.x release, we need a newer MSRV, because the pest_meta
(transitive) dependency does not build with 1.60.0 anymore.

So we update the MSRV here.

Signed-off-by: Matthias Beyer <[email protected]>
@matthiasbeyer matthiasbeyer changed the title [release-0.13.x] Update MSRV to 1.60.0 [release-0.13.x] Update MSRV to 1.61.0 Oct 23, 2023
@matthiasbeyer
Update MSRV to 1.63.0
6f08812 
For the next 0.13.x release, we need a newer MSRV, because the rustix
(transitive) dependency does not build with 1.61.0 anymore.

So we update the MSRV here.

Signed-off-by: Matthias Beyer <[email protected]>
@matthiasbeyer matthiasbeyer changed the title [release-0.13.x] Update MSRV to 1.61.0 [release-0.13.x] Update MSRV to 1.63.0 Oct 23, 2023
@matthiasbeyer
Copy link
Member Author

I don't like where this is going...

@matthiasbeyer
Fix clippy: use first() instead of get(0)
afe0b85 
Signed-off-by: Matthias Beyer <[email protected]>
(cherry picked from commit 8b2bdfe)
Signed-off-by: Matthias Beyer <[email protected]>
@matthiasbeyer matthiasbeyer mentioned this pull request Oct 23, 2023
Merged
@matthiasbeyer
Copy link
Member Author

UUuuh all green now. @ijackson you're welcome to experiment on another solution. If that does not work out, we can merge this PR instead.
But I'll wait for your stuff. And no need to hurry if you cannot get it done tomorrow - I have time! 😆

@polarathene
Copy link
Collaborator

I don't like where this is going...

There's a cargo command (third-party IIRC) that can be used to identify the MSRV for a project based on its dependencies I think?

You may want to also manage it in the Cargo.toml as one of my PRs mentioned.

@ijackson
Copy link
Contributor

Instead of this MR, how about the approach I took in #492 ?

@polarathene
Copy link
Collaborator

FWIW, cargo-msrv could detect the requirement with dev-dependencies too. It supports providing a custom command such as cargo check --tests. This avoids the approach taken in this PR with incremental bumping until the CI is happy.

The MSRV of many crates during my investigation were averaging around 1.63 / 1.64, others with 1.60. Since @ijackson has an MSRV of 1.65, you could probably consider 1.64 going forward.

1.63 is also apparently what the current Debian stable (Bookworm) release is using, which is an MSRV target for some projects, but Debian is rather slow pace, other crates have an MSRV policy that would / has moved on from that. Less of an issue when they adopt rust-version in Cargo.toml.

I think Cargo.toml can address the current CI issues with a Cargo.lock.msrv file (seems best practice?) and set a 1.56 rust-version.

Nothing else in config-rs for this branch requires raising the MSRV beyond deps and how they're resolved by default, that doesn't really warrant raising rust-version unless you want to update Cargo.toml in a way that'd require it. MSRV policy is different AFAIK, and some CI will use a higher MSRV for running tests (rust-version can still be verified separately).

TL;DR

  • MSRV / rust-version bumping as a response due to implicit dep updates should not be necessary.
  • rust-version is more accurate representation of what the project can build with.
    • Explicit changes to Cargo.toml or project code may require raising rust-version.
    • MSRV bumps are not considered a semver breaking change.
      • Especially when it's inherited from dependencies without adjusting Cargo.toml. That would likewise already affect prior releases that have been published since.
      • Treating as a semver breaking change can cause more issues, as would have been the case with log. rust-version better resolves this concern.
    • Bumping it may be valid if generating / resolving a Cargo.lock becomes unwieldy to maintain.
    • I don't really consider it applicable as a constraint to building examples or running tests, aka dev-dependencies, at least when Cargo.lock is committed.

@polarathene polarathene mentioned this pull request Nov 5, 2023
Merged
@matthiasbeyer
Copy link
Member Author

0.13.x is now no longer the latest release, so I'll close this unmerged. All patchreleases go to 0.14.x now.

@matthiasbeyer matthiasbeyer deleted the release-0.13/update-msrv branch February 1, 2024 06:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@matthiasbeyer @polarathene @ijackson