It needs to bump epoch and utils for -Zminimal-versions.

I know that "is bumping MSRV considered a breaking change?" problem is about as hard as P ?= NP, and I would fully accept and agree with any maintainer's decision here without further argument.

However, I'd like to lay the reasons why I personally think it would have been better to not make a semver-incompatible release in this case.

First, it creates additional works on the users who use crossbeam crates as public a API. For example, I maintain an lsp-server crate, which uses crossbeam-channel in public API. With this new release of crossbeam channel, I need to publish a new release of my lsp-server crate (update Cargo.toml manually in two places, commit & tag, cargo publish), and then I need to update lsp-server version in rust-analyzer (again, manual Cargo.toml change). If this were a minor upgrade, I would only need to run an automated cargo update in rust-analyzer's repo, without touching lsp-server at all.

Second, this change hurts compile times for large projects: rust-analyzer will have two copies of crossbeam in its crate graph for quite some time, as propagating updates across the ecosystem takes time.

Third, I am sure hardly anyone would have noticed an MSRV bump from whatever it was previously to 1.28 anyway. 1.28 is extremely conservative (that is excellent, thank you!). rayon uses 1.28.0 and it is notorious for sticking with older rustcs. lazy_static bumped MSRV from 1.24 to 1.27 three months ago in a minor release, and, from what I can tell, nobody complained about this. (In other words, it makes more sense to treat MSRV change as breaking if it is not conservative, but 1.28 is very conservative, as the ecosystem goes).

To clarify, my goal here is not to do something right now, but rather to make sure that, in the future, in this and other projects, publishing a non-semver compatible update is more carefully considered.

I see that this was discussed a little, and the argument was "lazy static made a breaking change, which affected our CI, so breaking changes are bad". However, lazy_static did this very intentionally and with a good reason: there are trade offs here, and making this a semver-incompatible change also creates additional work on various folks. A solution for CI breakage is to use a Cargo.lock file when running tests with MSRV.

I also can't help but appreciate a fine irony of the fact that bumping lazy_static's MSRV (for which I am to blame) caused me, indirectly, to write this comment :)

References:

rust-lang/api-guidelines#123

EDIT: there's actually a forth reason: lazy_static is a dependency of crossbeam-utils, and, as it can bump MSRV in a semver-compatible release, additional guarantee of crossbeam doesn't actually add much.

Thank you for writing this up! I agree with you and we should change our policy on whether bumping minimum version of Rust is a breaking change.

But, more importantly, I think we really should bring Crossbeam to 1.0 soon. I will follow up with an issue on what changes we need to do to get there.

One additional thing I've noticed: the umbrella crate crossbeam did not made a breaking change, it just bumped major versions of it's public deps, which is, dejure, a breaking change (which doesn't mean it creates problems in practice, only bug reports will tell :) ).

I will admit it: this was a very rushed and belated release.

Part of the reason is the fact that I dread making releases because they're so time-consuming and finicky (update readmes, changelogs, and Cargo.tomls for every crate, fix up dependencies, publish to crates.io, publish git tags) and I always make mistakes while releasing new versions. I don't think there's been a single release that went smoothly without mistakes.

Grouping all (or most) crossbeam crates into the main crate (kind of like what tokio is doing these days) and publishing 1.0s would alleviate this pain for everyone.