base64ct: feature edition2024 is required

[t3hnar]

Looks like this commit broke stuff on our side

Can you please advise on the best way to fix this?

error: failed to download `base64ct v1.7.0`

Caused by:
  unable to get packages from source

Caused by:
  feature `edition2024` is required

[leonardoalt]

Same here. You can pin base64ct = "=1.6.0" in your outermost workspace/package.

[tarcieri]

Yes, MSRV has been bumped to Rust 1.85. If you're unable to upgrade to Rust 1.85, you need to pin the version in Cargo.toml.

[t3hnar]

something weird is going on here, we do not have base64ct in dependency tree

[tarcieri]

To make a more specific statement here:

We painstakingly maintain MSRV compatibility for several years, however edition bumps are a time when users of crates need to expect a coordinated MSRV bump across the entire ecosystem.

We are doing a 2024 edition upgrade across all of our crates. I'm sorry if that causes inconvenience, but you can expect that more and more crates you use are going to start requiring the 2024 edition soon.

As was called out in our MSRV policy, we called out MSRV as not being part of our SemVer policy, and going forward we plan on more liberally raising MSRV now that there is an MSRV-aware resolver.

The MSRV-aware resolver should make these sorts of upgrades less painful going forward, but we can't get there without having an MSRV bump first.

[t3hnar]

@tarcieri thx

[tarcieri]

tl;dr: of how to work around this:

• for bin crates: pin to base64ct v1.6.0, ideally with a comment like "remove this when MSRV is 1.85 or above"
• for lib crates: create a Cargo.lock.msrv or thereabouts where all of your dependencies have been resolved with compatibility for your supported MSRV. You can use the MSRV aware resolver to select compatible versions

[jvff]

Would it make sense to release version 2.0.0 with the MSRV bump? That could avoid breaking semver compatibility with the old MSRV, especially if the crate is used indirectly.

[tarcieri]

It's something we could potentially consider, yes, although our SemVer policy with respect to MSRV was the following:

We may change the MSRV in the future, but it will be accompanied by a minor version bump.

[jvff]

I see. I think the issue in this case wasn't especifically the MSRV, but maybe the edition change? 🤔

[tarcieri]

The edition change is what requires an MSRV bump (in addition to other things like a migration to the core::error::Error trait)

[tarcieri]

Re: v2.0.0 however, there are other breaking changes that it would be nice to experiment with, so I don't think we should hastily release a v2.0.0 just for the MSRV bump without first considering other breaking changes

[tarcieri]

I'll reopen this and sticky it for visibility

[ptdecker]

This is causing nightmares in our org this morning. Trying to work around it now. Wish this had not been a sudden breaking change

[GPSnoopy]

You do realize that you have broken common tools such as cargo install nextest?

Because the dependency on edition2024 was done as a minor version upgrade of base64ct, any crate that does not specifically pin their dependency to 1.6.x will break on any Rust toolchain that is lower than 1.85.0.

You have effectively mandated that any crates, any projects that depend on base64ct, whether they are direct or indirect dependencies, now require Rust 1.85.0?

Within a few hours of releasing this version, you've already broken entire development pipelines.

I strongly suggest you yank this version right away, and then take time to reconsider the versioning for such a change. Yanking is the only sane option at this point before any further considerations, given the scale of the breakage that this change has caused.

[ptdecker]

In our case, this is actually a sub-dependency

│   ├── elliptic-curve v0.14.0-pre.5
│   │   ├── pem-rfc7468 v1.0.0-pre.0
│   │   │   └── base64ct v1.6.0

The above shows it before the change by building with '--locked'

[tarcieri]

I went ahead and yanked it.

I guess we'll have to release this as v2.0.0 because apparently calling it out in our SemVer policy is insufficient.

I am personally very frustrated with this outcome as this is a now a major blocker in our next release series and don't particularly appreciate the tone of some of the complaints here (going forward, if you’d like to inform us that we’ve broken a major tool, there’s a nice way to do that without leveling accusations and invective), but hopefully this ends the deluge of complaints.

Hopefully going forward the MSRV-aware resolver will address the general problem.

[sunshowers]

Main nextest maintainer here.

@GPSnoopy:

I strongly suggest you yank this version right away, and then take time to reconsider the versioning for such a change. Yanking is the only sane option at this point before any further considerations, given the scale of the breakage that this change has caused.

First off, this kind of tone is beyond unacceptable to use with a maintainer of an open source project. They are giving you something that is free, in both the gratis and libre senses. If you don't like the gift and can't provide feedback gently and constructively, "the only sane option" is to not say anything at all.

To be clear, if you filed an issue on the nextest repo with a similar tone, I would treat it as a CoC violation. I would give you one warning, then ban you from the GitHub organization. In fact, since you invoked nextest to go after an upstream maintainer, treat this as your one and only warning.

Second, the scale of breakage is not that large. The nextest repo itself was not impacted by this change because we check in our Cargo.lock file. You, too, should check in your Cargo.lock file, especially if you're using a version of Rust other than the latest stable version.

You do realize that you have broken common tools such as cargo install nextest?

This is not true. The nextest documentation very specifically says you should use --locked, and that an install without --locked is not supported. It is not our problem these very clear instructions aren't followed, and it is certainly not an upstream dependency's problem.

Because the dependency on edition2024 was done as a minor version upgrade of base64ct, any crate that does not specifically pin their dependency to 1.6.x will break on any Rust toolchain that is lower than 1.85.0.

You have effectively mandated that any crates, any projects that depend on base64ct, whether they are direct or indirect dependencies, now require Rust 1.85.0?

This is true only of projects that don't check in Cargo.lock. Please check in your Cargo.lock!

Within a few hours of releasing this version, you've already broken entire development pipelines.

Only the ones that don't check in Cargo.lock -- but those pipelines were broken anyway.

---

@ptdecker:

This is causing nightmares in our org this morning.

Given that you likely don't have a support contract with the maintainers of this crate, this is 100% your problem, not theirs. You are using open source software given to you for free. This is a tremendous gift given to your organization with incalculable value. In return, are you making maintainers' lives easier or are you making them harder?

Trying to work around it now. Wish this had not been a sudden breaking change

The Rust community consensus is that MSRV changes are not semver-breaking -- that doing them in a minor version is acceptable. This is okay because the semver spec's item 1 says:

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive.

In other words, a written MSRV policy in documentation counts as public API. base64ct's policy is that:

We may change the MSRV in the future, but it will be accompanied by a minor version bump.

This change was well within the policy constraints. (And even if a policy wasn't written down, these things generally fall back to community standards, and with Rust the clear custom is to not treat MSRV changes as semver-breaking.)

---

In sum, please remember that the people on the other side of the screen are humans providing you something of great value for free, and please treat us appropriately.