iliekturtles/uom

Bump MSRV

therealfrauholle opened this issue · 3 comments

therealfrauholle commented

I want to discuss bumping the current MSRV of 1.43. In my latest attempt to add support for the defmt framework (see #386) I could not use defmt, since it requires at least rust 1.56.

Besides helping me solve my problem, I also saw that bumping the MSRV could solve some more problems, e.g. #216 or #82; and probably more.

Even thought it may break builds for others, most major crates do not treat bumping the MSRV as a breaking change. I checked a discussion crossbeam-rs/crossbeam#503 for reference, there are some very interesting and valuable comments regarding bumping the MSRV there.

@iliekturtles can probably judge better how dependents use uom (and what MSRV they need); but I checked some of the dependents through crates.io and cargo msrv, these are the three most downloaded crates that use uom:

  • battery depends on uom:0.30.0; does not build below 1.46; last commit 2 years ago; mainly used in the actively maintained bottom crate which does not build below 1.61
  • heim-common depends on uom:0.30.0; does not build below 1.56; last commit 1.5 years ago.
  • starship-battery depends on uom:0.30.0; does not build below 1.40; part of the actively maintained starship crate which specifies a MSRV of at least 1.60.

These are the three most downloaded crates that use the most recent version:

  • sgp4-rs depends on uom:0.33.0; does not build below 1.56
  • libmedium depends on uom:0.33.0; does not build below 1.56
  • rtforth depends on uom:0.33.0; does not build below 1.56; last changes 23 days ago.

So by looking at this I think it is reasonable to assume bumping the version to 1.56 will not be a deal for most people. Speaking more generally, I suggest to make a MSRV policy similar as discussed in crossbeam-rs/crossbeam#503, that gives users a guarantee that uom will never have a MSRV newer than 6 months, but uom contributors have the chance to bump the version somewhat regularly to make use of the newest stable features. What is your opinion @iliekturtles?

therealfrauholle commented

Possible duplicate of #239 I just saw.

iliekturtles commented

Copied from #216 before I caught up with this issue:

I'm interested in bumping the MSRV but I'm a bit hesitant to go all the way to 1.60 when the work-arounds to resolve #216 issue aren't too painful and allow for an older MSRV. I don't have a specific policy about when to update the MSRV and what version to jump to so I'm interested in hearing thoughts about going all the way to 1.60.

After (mostly) reading the Crossbeam thread and now that I've seen the defmt PR I'm more inclined to jump to 1.60. It is ~6 months old if the defmt feature gets accepted alongside serde why deal with feature name work-arounds for both.

Whatever MSRV we jump to I would like to release the current master as v0.34.0 now. Finally get @crystal-growth's remaining quantity/unit PRs merged into a branch to be released as v0.34.1 and allow for changes that need the new MSRV to start being merged into master.

  • 👍1
iliekturtles commented

https://github.com/iliekturtles/uom/actions/runs/5365520967/jobs/9734386156?pr=421#step:4:53

log has a MSRV of 1.60.0. I'm looking at this now to fix all the bitrot with the github action failures.