Version 1.0.2 broke semver

[tcharding]

The v1.0.2 upgrade included an upgrade of the base64 dependency from 0.13 -> 0.21. This implies that, to follow semantic versioning rules, the release should have been 1.1.0

Folks trying to build your crate with a version of Rust that does not support edition 2021 now have to pin the version to 1.0.1 in order to be able to build.

[djc]

As far as I can tell it's pretty common practice to bump the MSRV without bumping the minor version, although I admit that most crates I use are not on 1.0 yet so there is no opportunity to only increase the minor version (without breaking compatibility). Additionally, most crates use rustls-pemfile in combination with rustls, which has required 1.56 for a while now.

What's your use case for sticking to such old compilers?

[apoelstra]

I am a maintainer for the rust-bitcoin project, which is the downstream project that has this MSRV rule. Our use case is pretty straightforward -- we don't want to force our users to upgrade their compilers unnecessarily, so we try to space our our MSRV bumps by a lot, and make sure these bumps coincide with major version publications. In addition to "don't upgrade until we have to", our specific criteria for bumping this are:

• Any new MSRV should be widely distributed (in practice this means: it is available in Debian stable)
• It should be supported by mrustc, or within a couple versions of one supported by mrustc, for people who are bootstrapping compilers (e.g. through guix) and want to be able to bootstrap from C++
• It should be at least 2 years old, so that on the off chance both Debian and mrustc act super fast, people still have a lot of time to prepare for the compiler upgrade, any CVEs that are going to be found have been found, etc.

2 years sounds like a crazy-long time in the Rust world but it's actually a crazy-short time in pretty much any other programming language. Or at least, any other "systems" programming language such as C or C++, which are the sorts of languages our users are likely to be accustomed to.

Because our code focuses on cryptography, and specifically financial cryptography, we take "trusting trust" issues very seriously, and try to push the envelope on this front -- by minimizing dependencies, having a very conservative MSRV policy, and contributing to projects such as guix and cargo-crev which attempt to make our software chain reliable and authenticated.

Having said that, while I agree with @tcharding's claim that MSRV increases ought to be considered semver-breaking, I also realize that the wider Rust ecosystem disagrees with me (and that there is a documented "cargo semver" which does not consider MSRV changes to be breaking). I also appreciate that it really ought to be cargo's job to keep track of rustc compatibility -- and there is active work on this front -- and that putting the onus on individual package maintainers is a burden that they may not agree with.

It's also true that by bumping the major rev of a crate, especially one that exports traits or other "compatibility" types, the cure may be worse than the disease, because the result would be a bifurcated ecosystem where old-MSRV users now have incompatible types with new-MSRV users. This can be ameliorated by moving traits and types into dedicated crates ... but now we're at an even heavier maintenance burden.

In conclusion this is the perspective we're coming from, and we ask you kindly to consider it.

[djc]

Thanks, I do appreciate the extra context. For what it's worth, the initial issue description came off as a little entitled to me, particular given that it asked for something that is at odds with how most of the ecosystem operates.

First off, with my library maintainer hat on I usually consider myself to be on the more conservative side of the MSRV discussion. For example, I commented on the libc discussion, argued for reducing the MSRV in clap and reducing it in async-global-executor, and I maintain chrono 0.4.x at 1.38. I also contributed the current rust-version support to Cargo.

At the same time, the ecosystem has clearly moved on. Many crates have started requiring 1.56 or newer, and there is now substantial movement to move towards 1.60 or even 1.64. And in my role as a volunteer maintainer, working around these core dependencies upgrading their MSRV is a pain in the ass, and doesn't feel like a particularly high-value thing for me to spend my spare time on.

The libraries get to move more aggressively because most of the Rust developers also move more aggressively. And as a Rust developer, and a CTO of a company using Rust, I adopt the latest stable on release day. IMO the quality of most software (including in the Rust ecosystem -- although perhaps base64 is not the best example) usually increases; newer versions almost always have fewer defects. For compile times, I prefer my dependency graphs not to have a bunch of copies of the same crate at different versions. And, of course, while you're free to use an old rustc compiler, the Rust project doesn't support you doing that, and leaves you (or your distributor) to ensure important fixes are backported.

In that sense, the Debian practice of only updating packages every 2 years or so seems anachronistic to me, a reminder of an earlier time when software moved more slowly. And just as even for your project the majority of users probably still use a Rust release newer than your MSRV, an even smaller contingent will actually go through the trouble of bootstrapping from whatever base they think they can trust.

So, going back to my role of rustls-pemfile maintainer, I would have been happy to consider a request to bump the version to 1.1.0 instead of 1.0.2 to make your life easier, because it would not have cost me very much. But, having already released 1.0.2, and given the described ecosystem dynamics where what we did here is pretty common practice, I don't feel like it's worth my energy/time to go back and yank that version only to redo the release as 1.1.0.

[apoelstra]

Thanks for the thorough reply. I'm fine to close this issue then.

[tcharding]

For what it's worth, the initial issue description came off as a little entitled to me, particular given that it asked for something that is at odds with how most of the ecosystem operates.

My apologies if that is how it came across, that was not my intention. My intention was not to ask for anything but just to bring it to you attention that this happened in to off chance that you did not realise when you did the last 1.0.2 release.

[djc]

Apologies accepted! I still think most of the ecosystem doesn't do semver the way you are proposing here, but I should probably consider it the next time I bump the MSRV on a 1.x+ crate.

[tcharding]

Thanks man! One dev at a time :)