Changing metadata should be possible without bumping a version

[lifthrasiir]

Currently Cargo doesn't allow the metadata to be separately updated. This doesn't seem right (as the semantic versioning only concerns about the public API and the metadata is not a part of the public API).

In order to fix this issue, the publish endpoint (/api/v1/crates/new) should be adjusted to accept the metadata without the tarball (well, or have a new endpoint for that), and the server will check if the name, version, dependencies and features match to those stored before updating that. In the CLI the cargo publish command should ask for the metadata update when the version hasn't been changed.

[sfackler]

👍

[Folyd]

Any progress on this issue?

[carols10cents]

If there was any progress, it would show up on this issue.

[epage]

I feel like the trend has been to remove metadata from source, like https://rust-lang.github.io/rfcs/3052-optional-authors-field.html or crates.io deciding to stop showing badges.

[epage]

Moving this to crates.io as they should be making the decision on what metadata is mutable and how users should edit it (web UI, cargo command, etc). From there, they can request any desired cargo features to accomplish the wider goal.

Most likely, someone will need to step up to drive this forward to look into what metadata should be mutable, why, and what workflows best fit with that context.

[hi-rustin]

I think the trick part is we also package Cargo.toml[.orig] in .crate file. If crates.io only allows to update the metadata. Then the metadata of Cargo.toml[.orig] from the .crate would be different from the database.

Also, I think it would also affect the checksum check of the tarball file.

[retep998]

The metadata in the crate itself should not be mutable. Instead the metadata from the crate should be used as the default value displayed on crates.io, but the user can then change the metadata visible on crates.io via the web UI, without affecting the metadata actually stored in the crate.

[hi-rustin]

but the user can then change the metadata visible on crates.io via the web UI, without affecting the metadata actually stored in the crate.

I think this kind of inconsistency would cause a lot of confusion.

Can I ask what kind of metadata you only want to change in creates.io instead of Cargo.toml?

[hi-rustin]

See: https://blog.vlt.sh/blog/the-massive-hole-in-the-npm-ecosystem

And #7194 will force us to use these fields from Cargo.toml.

[Turbo87]

I just rediscovered #3167, which basically describes the same thing. Let's move the discussion over there to not have two duplicate issues :)