For internal tracking purposes with a private registry, my company uses the + semver syntax on crate versions. It's effective for our use case, but every cargo build emits this sort of message:
warning: my-crate/Cargo.toml: version requirement 0.6.1+internal_info for dependency my-crate includes semver metadata which will be ignored, removing the metadata is recommended to avoid confusion
How do I disable it? It's distracting for developers, and given it's a valid use of semver semantics, I don't feel it's the role of cargo to tell me how or how not to use semver, at least in a private repo context (I see the argument for crates.io publishing, but this is at build time).
First of all, do understand what the warning is telling you? It means that + metadata does nothing when written in a version requirement in a dependency specification. So, it is basically a comment, and it could be replaced with a # comment in the TOML file while getting the same effect.
Given that, if you still want to use +, I think the path to not getting warnings is that the warning should be migrated to Cargo’s just-stabilized lint control system, which would allow you to simply turn it off.
Yes I understand the warning. No one in my company is confused by the +. It's for internal auditing purposes, and a TOML comment is not as effective nor what we want.
As an aside, I'm not sure what's confusing about it. The specification is quite clear the metadata is not involved in version resolutions.
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. [...] Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.
Glad to know there's a new lint control system. Not sure how to advocate for moving it there, but since I guess there's no other way (I was hoping for a logging filter) I can hope.
Well, the tracking issue says in a couple places that the intent is to convert all existing warnings to the lint system. So, the thing that is needed is not advocacy, but work.
Today, cargo maintainers are very cautious as to what warnings are created because they cannot be turned off by the user when they are intended. The problem is we've not had a mechanism to control it. …
As package and workspace level lint control, turning existing warnings into diagnostics where possible
But I don’t know exactly what T-cargo wants the process to be. Perhaps a simple PR converting an existing diagnostic would be welcome, or perhaps there should be an issue or discussion on #t-cargo first.