Rust Roadmap: libc v1.0 release

[coder543]

• According to the roadmap, Rust should have 1.0-level crates for essential tasks.
• According to crates.io, libc is the most downloaded crate of all time.

Therefore, it follows logically that libc must have a v1.0 release according to the Rust roadmap.

I am opening this issue so that a plan can be formulated and then executed upon.

• What would it take to get libc to v1.0?
  • I see some issues marked as 1.0-breakage, so those would need to be done, but it looks like people are holding off on doing them until closer to the currently-nebulous release date for v1.0.
• When should a v1.0 release happen?
  • We could wait until the end of the year, or we could go ahead and make good on this portion of the roadmap, starting with libc.

[lambda]

Aside from the issues tagged 1.0-breakage, which seem simple enough to deal with, I think that the big outstanding question is #180, that libc's c_void is not the same type as std's c_void (also filed as rust-lang/rust#31536). There's been some substantial discussion of this on internals, and there is an active RFC with considerably more discussion.

[SimonSapin]

I’m very opposed to making a 1.0 release just because. Upgrading from 0.1 to 0.2 was a huge pain. In Servo we had to coordinate upgrades of 52 dependencies: servo/servo#8608. Upgrading only some dependency but not others would cause build errors because they typically use some libc type (like c_void) in their public API.

And wasn’t just Servo. crates.io lists 1210 reverse dependencies for libc now.

I think that a much better justification than just getting a nicer-looking version number should be needed to force the ecosystem to go through that again.

[coder543]

I'm very opposed to making a 1.0 release just because.

It's on the official Rust Roadmap. It's very hard to argue that libc isn't essential. The reasoning is detailed on the issue here. That alone should be reasoning enough to do the upgrade.

However, @lambda has pointed out that issue #180 needs to be resolved. If #180 were resolved, that would be a significant change, and that should warrant a big upgrade, should it not? So, one way or another, this needs to happen in 2017, and maybe we can make a significant fix to the c_void type at the same time, which would be nice to have.

It makes a lot of people nervous to depend on libraries that declare themselves unstable, yet libc has definitely reached maturity and should be considered stable. Updating the version number is an important symbolic step, and is not a trifling thing done "just because". However, I would agree that it should only be done when major issues like #180 are resolved. I think we need a roadmap for fixing that issue.

[SimonSapin]

If people feel strongly enough about the nicer-looking version number, one way that I think would be acceptable is:

• Make 1.0 compatible with 0.2. This means not fixing any of the issues labeled 1.0-breakage.
• Somehow teach Cargo that they’re compatible, so that it could select 1.0.0 when a crate declares a dependency as libc = "0.2.18", for example.

@coder543 the issue you point to says “1.0-level” in the title. That’s a subjective judgment of quality, not a version number. 1.0.0 as a version number can be a signal that maintainers believe a project has this level of quality. Is this signal worth making hundreds of crates coordinate to upgrade?

[SimonSapin]

The only way I can think of that fixing #180 is a breaking change is if a crate implements the same trait separately for std::os::raw::c_void and libc::c_void. I don’t know if such breakage is major or minor.

[coder543]

What you suggest would require breaking semver in Cargo, so I don't think that's going to happen.

Would you prefer that libc never have another breaking release? It will happen eventually. When it does, I believe that we should also update the version number to 1.0.0. The idea of having a 1.0-level release is to have releases that are subjectively of good quality, and part of the subjectivity there is in the version number, not just the code contained within. People who don't live and breathe Rust can't be expected to understand that version 0.2.x is considered stable, and their management is especially not going to be understanding of that.

I want Rust to have as few obstacles to being used in production as possible, and when management sees dependency on libraries that are below v1.0, that's going to be an obstacle.

[tomaka]

According to the roadmap, Rust should have 1.0-level crates for essential tasks.

Is interfacing with the libc an essential task? I don't think so, as most of what it provides is already provided by the stdlib.

Most people that depend on libc do just because it provides the c_* types, but they should probably use the types in std::os::raw instead of using libc.

[SimonSapin]

Would you prefer that libc never have another breaking release?

Yes. And url (which I maintain), and serde, and some others.

When a library gains in popularity, especially among other libraries that expose it in their respective public APIs, any breaking release becomes increasingly more painful. This is the "other side of the coin" of enforcing SemVer in Cargo.

[lambda]

1.0.0 as a version number can be a signal that maintainers believe a project has this level of quality.

I think more important than "level of quality" is "level of stability". In a production project, I don't want to use some crate, have the project work and be deployed for a while, then suddenly need to add some new feature that depends on updating some dependent crate, and discover that due to having many recursive dependencies that were not at a stable point, having to do a whole bunch of work to clean that mess up.

Essentially, the signal that 0.2.x sends me is that at some unpredictable point in the near future, I'll have to deal with the very problem you describe, of having to do a whole bunch of work to fix up a whole ecosystem of dependencies. A 1.0.0 release signals to me "we think that this is ready to support stably for a long period of time, so there won't be gratuitous ecosystem-wide semver incompatible bump in the near future".

Now, is it worth actually breaking the existing ecosystem in order to help prevent this worry? I'm not sure. Simply documenting that for libc, 0.2.x is considered to be stable and supported for the long term may be sufficient, there are plenty of other widespread open source libraries that have always or for many years been under 1.0 but still considered stable. But it is worth thinking about the version number as a stability signal, rather than a quality signal.

[coder543]

Yes. And url (which I maintain), and serde, and some others.

That's not being realistic.

Breaking changes have to happen eventually or things will stagnate forever.

[SimonSapin]

That's not being realistic.

Of course. “Not ever” is an exaggeration of “not unless the benefits outweighs the costs that we know (and learned the hard way) to be very high”.

[lambda]

Yes. And url (which I maintain), and serde, and some others.

When a library gains in popularity, especially among other libraries that expose it in their respective public APIs, any breaking release becomes increasingly more painful. This is the "other side of the coin" of enforcing SemVer in Cargo.

Indeed, at some point you want to commit to long-term stability, and accept the warts in the interface and work around them in backwards compatible ways.

Serde in particular is the one that has bitten me the most here. But I would actually like serde to get to 1.0 so that I know when I'll stop having to be on the upgrade treadmill to keep up with the ecosystem. Right now, due to my previous experience with the API changing, I'm wary of relying on it heavily until that happens. Likewise, the 0.2 version number of libc, and previous libcpocalypse, makes me a little wary of relying on it as well.

I think that while the release to bump to 1.0.0 will be painful for many of these crates, ripping off that bandaid and sending the signal that that's the last time that will happen in quite a while is the big benefit of the push to 1.0.0-level crates. There is a bit of a sense of "Rust is stable now, but the ecosystem is not" that holds people back from depending on it.

[steveklabnik]

Simply documenting that for libc, 0.2.x is considered to be stable and supported for the long term may be sufficient, there are plenty of other widespread open source libraries that have always or for many years been under 1.0 but still considered stable.

IMHO, the Rust team should lead here, and get it to 1.0.

I agree with @SimonSapin that this shouldn't be taken lightly, as it will be painful. But it should be done.

[metajack]

I think the argument here is not don't do it, but don't do it unless there are meaningful breaking changes to justify it. Republishing what we have now as 1.0 just creates a ton of work to achieve a more appealing version number.

The last libc breaking upgrade was a huge time sink, which we often refer to as the libc-pocalypse. I may be wrong, but I think we probably discussed calling the current version 1.0 back then for this very reason.

When it does happen, I suggest not just publishing the crate and moving on. Actually do the work to get the whole ecosystem upgraded as quickly as possible; know that this is going to cause amazing grief and be prepared to help.

[tbu-]

It would be easier to upgrade once Cargo understands the difference between public and private dependencies, I guess – the problem last time was (AIUI) that Cargo decided to use mutually (semver-)incompatible versions of libc together where it was a public dependency, i.e. one whose types were reexported/used in public interfaces.

Once Cargo understands public/private dependencies, there incompatible versions of libc won't appear in one project where they're used together, so there should be no upgrade churn.

Cargo issue: rust-lang/cargo#2064.