-
To clarify this a bit:
1. The widely used Time crate had some code which converted to an unspecified type. The code then converted this again in a following line. Because there was only a single possible (identity) conversion, this code was a noop. Regardless this was fixed in time@0.1.35 (released in April 9, 2024). [1]
2. Rust 1.80 (released July 27, 2024) introduced a new trait implementations that made the second conversion now cause the first conversions to have two possible inferences. [2]
3. Rust packages that upgraded the compiler to 1.80.0, but used a version of the time crate prior to 0.1.35 fail to build the time dependency. This is mitigated by the fact that 0.1.35 is a semver compatible update, which just requires running cargo update to use.
[1]: https://github.com/time-rs/time/pull/671
[2]: https://blog.rust-lang.org/2024/07/25/Rust-1.80.0.html#stabi...
Something that would be neat to see from Rust here would be a way to measure the impact of these sorts of compiler and dependency bumps in order to reduce the blast radius of this sort of thing. Ideally being able to say "this change requires X devs to do process which cost Y minutes, so it's worth investing Z minutes to avoid / document it". I often want to make public API changes to a library I maintain, but the best tool I have for understanding who those changes will affect is often a GitHub search for code.
-
InfluxDB
Purpose built for real-time analytics at any scale. InfluxDB Platform is powered by columnar analytics, optimized for cost-efficient storage, and built with open data standards.
-
I work in a large code base with 1800+ crate dependencies (don't ask) with half of them being unstable crates not really published to crates.io. And yeah, we run into this issue a lot. The recent one was caused[0] by human error, it's usually human error but there's also a lot of cases due to Cargo's choice to go to pick the highest version that satisfies the constraints. It's a reasonable choice on Cargo's part but yes, our team has learned to be very conservative to diffs on `Cargo.lock` and most of our dependencies are pinned.
[0]: https://github.com/denoland/deno_core/issues/797
-
The fact that you can just `cargo update` is besides the point. The standard library should never make a breaking change that breaks running code. Why is this the exception? If the problem is that it wouldn't be possible to add new traits, then solve that by gating access to new traits on a minimum version.
It seems like the change should have been made as part of a new edition. This PR seems relevant: https://github.com/rust-lang/std-dev-guide/pull/66
-
(Rust playground maintainer here) Incidentally, I also updated the Rust playground today. My usual process is to update everything [0] that is SemVer compatible and then one-by-one update packages with SemVer incompatible version bumps.
During the upgrade, I was thinking to myself how generally I’m fairly blasé about these updates — I don’t even attempt to build the code with the SemVer compatible updates because it’s so rare for a crate maintainer to stuff up such an update. The SemVer incompatible updates get a build just as a sanity check.
Contrast this to the JS dependencies where an upgrade tends to instill more dread in me. Part of this is a lack of confidence in my test suite, part of it is that it’s the more UI heavy component which is hard to write tests for in the first place, but a non-zero part is my lack of trust in the JS libraries and tooling. I wonder how much of that is still true today versus how much I am once bitten, twice shy.
[0]: https://github.com/rust-lang/rust-playground/pull/1079
-
I hate to drag Go into this but I can't help but compare what happened here to the attitude here: https://github.com/golang/go/discussions/55092
My initial impression was that this is boiling the ocean but there's substantial foresight.
If I'm blowing this out of proportion then the bar is already too close to the ground for my liking. This is solvable.
I don't remember the last time a tool chain update broke my build. It's one thing if it's a bug fix. But for practically everyone to have to update?
If 100,000 developers have to trip over this, say, then with your 10 minute estimate that equates to a million minutes, nearly 8 years at 40-hour weeks.
This appears to be a problem totally worth solving.
-
>> I often want to make public API changes to a library I maintain
> They have such a tool, its called crater
There are tools out in the wild that help crate authors do similar things. For example, I wrote my own[0] to evaluate some breaking changes for SNAFU. There's also crater-at-home[1] which I don't have any direct experience with.
[0]: https://github.com/shepmaster/mini-crater
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
