base64ct: un-yank v1.7.0 or publish v2.0.0?

[newpavlov]

In the v1.7.0 release we have bumped MSRV to 1.85. Technically, it was done according to our policy.

But, personally, I considered MSRV bumps breaking changes and it was one of the reasons why I did not want to release v1-s until MSRV-aware lands and we update MSRV of our crates accordingly. In other words, for pre-v1 crates the claimed MSRV policy means that MSRV bumps are considered breaking.

The v1.7.0 release has caused issues for downstream users (see #1684 for more information), which led to the yanking. But we can argue that the fault lies with the users who did not use the --locked flag while installing binaries or did not commit Cargo.lock to their repositories.

We have two options: un-yank v1.7.0 or publish v2.0.0. Personally, I am fine with either with a very slight leaning towards the latter option.

[tarcieri]

I don't think we should publish v2.0.0 simply to bump MSRV, however there are other breaking changes we could consider making, and since base64ct is a simple library crate which doesn't have things like complex inter-crate trait dependencies bumping version and making breaking changes isn't terribly difficult.

The std feature could potentially be removed, though I'd need to see how important the From<Error> for std::io::Error impl actually is. never mind, Decoder/Encoder have std::io::{Read, Write} impls respectively.

Some of the internals of Alphabet leak out via the Encoding trait's supertrait bound. This is currently used by jose-b64, though that wasn't intended to be a deliberate part of the public API.

[baloo]

I'm a bit puzzled by the issue here.

We can't just bump the major revision every time we bump the MSRV. We've bumped MSRV in the past, and we will continue to. I guess people reacted because we bumped to the latest MSRV a couple of days after the release of the rust version, but even then, the problem is the lack of locked dependencies :(

[newpavlov]

We can't just bump the major revision every time we bump the MSRV. We've bumped MSRV in the past, and we will continue to.

Most of our crates are in the pre-v1.0 release state and we responsibly bumped MSRV only in minor releases, i.e. MSRV bumps were considered "breaking changes". Now with the MSRV-aware resolver and bump to the 2024 edition we relaxed this strict policy.

Now we have a problem with the minority of crates in the post-v1.0 release state. Technically, our policy allows MSRV bumps in minor releases, i.e. for post-v1.0 crates MSRV bump is no longer considered a "breaking change". As you can see, together with the uncommonly steep MSRV bump to 1.85 it creates issues for downstream users who use older tooclhains.

[tarcieri]

I think the biggest problem is the steep MSRV change, with 1.85 being quite new. Perhaps we should adopt a formal policy like N-{1,2,3} to prevent "MSRV shock" from requiring super new releases. But that could probably use its own meta issue.

[newpavlov]

Perhaps we should adopt a formal policy like N-{1,2,3} to prevent "MSRV shock" from requiring super new releases.

It could be a fine transition policy for post-v1.0 crates for which we do not want to cut a breaking release to just bump MSRV. But for other crates I think we should just migrate to the 2024 edition and fully rely on the MSRV-aware resolver (i.e. we should not shy from using the latest stable release if it contains a feature which we want).

[tarcieri]

Something we could do to make the MSRV bump a little less aggressive is roll back the 2024 edition bump and release 1.7.1 with just the core::error::Error impl. That would require an MSRV of 1.81 which is less aggressive, and then we can do a 2024 edition bump at a later time when 1.85 has been out a little longer (e.g. when 1.87 has been released)

[sunshowers]

Like I mentioned in #1684 privately to @tarcieri, I'd personally recommend an N-2 (i.e. last 3 stable versions) policy. There are times when we've had to hold off on Rust updates due to regressions (rust-lang/rust#132064 is a recent example). If they get picked for the beta branch then that's one version, and if they don't get picked then it's two. N-2 should cover that with a one-version margin for finding issues.

The MSRV-aware resolver will definitely help here as well, though people on slightly older Rust may want new APIs or bugfixes which is why "latest stable" might be too aggressive.

I would recommend against MSRV updates being breaking changes -- that tends to have ripple effects throughout the ecosystem, particularly for downstream crates that might expose base64ct as a public dependency.

[tarcieri]

Opened a PR to downgrade the edition to 2021 and MSRV to 1.81: #1702