libc: proposal to update minimum versions and release 0.3

[tgross35]

I would like to request the below be discussed at a meeting, or at least get team feedback before moving forward.

Context

Currently we maintain two branches for libc: main, which is intended to be 1.0, and libc-0.2 which is the current crates.io release. PRs are made against either channel (I usually request main so that always stays the most up to date) then get cherry picked to the other.

Usually this flow works okay, but there is a substantial difference in minimum supported versions: libc-0.2 is tested down to 1.19 and main is tested with 1.63. This makes some things difficult to keep in sync, e.g. #[repr(align(...))] and const fn cannot be used on 0.2. Cleaning these things up in main isn't even easy because it means cherry picks get conflict prone.

Proposal

I would like to create a new stable release of 0.3 that brings minimum versions closer to what we want for 1.0 and documents these in the README. Closing the gap in supported versions should make it easier to keep the branches in sync and do the desired pre-1.0 refactoring.

In particular, I am interested in the following versions:

• MSRV: 1.63.0, released 2022-08-11 (default on Debian stable, released 2023-06)
• musl: 1.2.3, released 2022-04-07 Rebase of "Upgrade musl supported version to 1.2.3" libc#3791 (supports Debian stable and Alpine stable)
• FreeBSD: unknown, maybe 11 or 12 (up to target maintainers, cc @asomers)
• Emscripten: 3.1.42, released 2023-06 if this seems reasonable to the target maintainers
• ESP-IDF: v5.0, released 2022-02
• Edition: 2021

All of these versions were selected because they allow removing version-specific configuration for those platforms. There might be some other targets that we would like to specify a minimum or tested version for, I'll check with the target maintainers.

Out of these changes, the only one that actually needs a merge before we can release is musl; everything else can just be a documentation change and then clean up the legacy support at some point after the release.

We might be able to do a few other breaking changes if they are small or ready (relevant milestone) but it seems better to keep 0.3 scoped to version changes.

Remaining for 1.0

There are still a handful of things we need to figure out between 0.3 and 1.0:

• How should extra traits be handled Discussion about removing extra_traits in 1.0 libc#3880
• Minimum glibc version Minimum Supported glibc version libc#1412
• What exactly should the scope of libc be Deprecate all Linux kernel APIs libc#1391

MSRV

#72 covers this ad nauseam and doesn't have a concrete conclusion. That thread has a lot of requests to support Debian stable but not too much for anything older than that, and 1.63 is what main has been testing on CI anyway. In the interest of avoiding too much of a bikeshed, I would only like to ask if anyone objects to 1.63 as too recent, i.e. that we should be supporting something older than latest Debian.

We can revisit a more official version policy before 1.0.

[BurntSushi]

I would rather see the MSRV updated in a semver compatible release. Otherwise, we're talking about two semver incompatible releases of one of the most widely used public dependencies. Is my understanding out of date, or is it still expected that that is going to cause significant ecosystem-wide churn and pain? I'm not even clear on why libc supports such an ancient version of Rust in the first place. In my view, it should be regularly bumped, just like I've done for regex. I still keep it conservative, but I do occasional MSRV bumps in semver compatible releases.

Now, if you need to make semver API incompatible changes before a 1.0 release, then obviously that would require a 0.3 release. But my sense of things here is that the main reason for 0.3 in this comment is to bump the minimum versions of build dependencies.

Otherwise, I do think this conversation should be framed around trade-offs here, to avoid heading down the well beaten path of "should MSRV bumps be treated as semver incompatible changes or not." And specifically, what kind of ecosystem pain we can expect from a semver incompatible release of libc.

[tgross35]

I think that most are in agreement that changing the MSRV in the future will not be considered a semvar-breaking change, and that is something we will document. However, my understanding is that we don't want to touch the MSRV in 0.2 at all because no policy was ever established and we don't know exactly what the fallout would be. It seems relatively unlikely for anyone to actually be relying on this, but a version bump seems like the cleanest way out we could get here.

Is my understanding out of date, or is it still expected that that is going to cause significant ecosystem-wide churn and pain?

As proposed I believe the 0.2 -> 0.3 update should be mostly painless, just an opt in the new MSRV policy, and then going to 1.0 would be the bigger change. Musl is the an exception here because 64-bit time_t does change definitions - we have really needed this change for a while (rust-lang/libc#1848) so it seemed worth the breakage vs timeliness tradeoff.

Anyway, the main goal is to no longer maintain a version of libc that needs to support < 1.63 since it seems to be getting in the way of moving toward 1.0. I don't think we can reasonably freeze the stable version completely since 1.0 is a few months away at the absolute minimum, and I don't think we can increase the MSRV of 0.2 because of the lack of policy mentioned above. A 0.3 just to bump versions seemed like the best shot at striking a balance (and was also proposed by @joshtriplett somewhere iirc).

[BurntSushi]

I don't think a lack of policy means we can't bump MSRV in a semver compatible release.

The pain I'm looking to see addressed is not really about the experience of migrating for one dependent. But of the whole ecosystem. libc is a public dependency. I'm not sure if you were around for the 0.1 to 0.2 transition, but it's affectionately referred to as "the libc-apocalypse" for a good reason. The problem is that you typically need to migrate your entire dependency tree over in whole.

This is why I'm asking if anything has changed to make that migration more bearable. If not, then we really should consider it a last resort. Bumping the msrv in a semver compatible release seems vastly preferrable.

[tgross35]

I don't think a lack of policy means we can't bump MSRV in a semver compatible release.

Okay; I thought that was the position at some point based on discussion at rust-lang/libc#2845 and from #72, but I guess maybe it was never actually a libs standpoint considering the PR was approved at some point.

I suppose that puts us back to the point of needing version policies for everything relevant, but that probably isn't a discussion for here. I'll likely put up documentation-only PRs that can be followed with actual changes once approved.

[BurntSushi]

FWIW, I don't have any official stake in this matter. So I'm not sure that I would close this issue on my word alone. :P

I think #72 got stuck in trying to figure out a long term policy. But if you're doing a conservative MSRV bump (and I think this is pretty conservative, and for example, accommodates tokio even for all of their active LTS releases if I'm reading their README correctly) for specific actionable reasons, then I think that's probably a different thing.

[asomers]

I just want to point out that libc's current MSRV policy is ridiculously conservative. Here are some stats:

• Of the 4000 most recently updated crates, 99% are incompatible with rustc 1.30 or older (https://lib.rs/stats)
• Of all crates.io requests that use a stable rustc compiler, 99.5% use rustc 1.65 or newer (https://lib.rs/stats)
• FreeBSD's package repository moved past 1.19.0 seven years ago. I don't have a good way to check when other OSes did. (https://cgit.freebsd.org/ports/commit/?id=97c4fb35a8312b8c6b781e0abc6eb2023413e7c9)

[cuviper]

I think moving libc 0.2 to MSRV 1.63 is fine, even if we disclaim any explicit policy at this time.

[tgross35]

I opened rust-lang/libc#4040 to document that libc 0.2 will raise its MSRV to 1.63