Warn/confirm about < 1.0.0 dependencies when publishing 1.0.0

[abonander]

I have two crates that I made the mistake of prematurely releasing 1.0 before their public dependencies had released their 1.0, both newbie mistakes but easy to make:

• abonander/img_hash

In this case I misunderstood semver and thought that a breaking change in 0.x required a bump to 1.x. Unfortunately this crate has image as a public dependency which is not 1.0 yet; I have been able to work around the issue by supporting a wide range of image versions using a minimal de facto-stable subset of its API.

• abonander/mime_guess

Here, because the API was simple and I figured I wouldn't need to make any breaking changes in the foreseeable future, I went ahead and released a 1.0 as was being encouraged at the time. Unfortunately the API is coupled to the mime crate which has two major pre-1.0 versions that are incompatible with each other. I was able to provide support for mime 0.3 by issuing a 2.0-prerelease but this has its own problems (#6016); I will probably have to fix this by publishing a new major version for every mime pre-1.0 version.

If I had realized soon enough I could have yanked the 1.0 releases but in both cases it wasn't made clear to me until long after the fact, several minor releases in after other people had started to depend on them and were assuming 1.0 was stable.

AFAIK, there is nothing anywhere in Cargo's documentation to remind the user that public dependencies are part of a crate's API and need to be considered when making the stability guarantee of a 1.0 release. It's not a hard conclusion to reach with a little bit of thought, but that unfortunately means it's easy for some people (including myself) not to realize until it's too late.

My recommendation is to notify the user when running cargo publish at specifically version 1.0.0 that any dependencies that are not 1.0 yet may be breaking changes to upgrade if any part of their API is reexported. To be sure they see and acknowledge the warning, it should probably require confirmation before continuing.

Since it would be exceedingly complex to determine whether any dependencies are actually reexported, this only needs to be a warning and not an error; and to avoid being overly repetitive it's really only necessary when releasing 1.0.0, or perhaps any version >= 1.0.0 when all previously released versions were 1.0-prerelease or less (in case the user accidentally/intentionally skips 1.0.0).

[mathstuf]

I believe there have been issues/RFCs/discussions on having an explicit private/public dependency in Cargo which could be leveraged here.

[mathstuf]

Also important is that, IIRC, there are some crates that are pinned to be pre-1.0 "forever" (libc comes to mind).

[KamilaBorowska]

I don't think there is anything wrong with 1.0 crates having public dependencies on pre-1.0 crates. It's perfectly fine to release 2.0 if that public dependency gets a breaking update.

Semver specification says the following:

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.

Rust ecosystem has plenty of crates that by all means should have been 1.0.0 and effectively can be considered to be.

[epage]

For the reason xfix gave, I'm going to propose to the cargo team that we close this.

If we did anything, I think it would be a lint (once we have linter) that only checks public dependencies.

[weihanglo]

Fair enough. Closing. Thanks everyone.