`cargo-c` version `0.10.5+cargo-0.83.0` is not detected as the latest version

mtelka commented 2 weeks ago

Projects affected

Observed behavior

The latest version 0.10.5+cargo-0.83.0 listed at crates.io is not detected as the latest one. Only 0.10.5 is considered latest.

Expected behavior

Version 0.10.5+cargo-0.83.0 should be accepted as the latest one too.

AMDmi3 commented 2 weeks ago

Done but that seems like upstream problem - the version is abused to include extra information, does not correspond to tags and as we can see nobody really use the suffix. @lu-zero

lu-zero commented 2 weeks ago

What would make your lives simpler? if the tag matches the version it would be better for you?

AMDmi3 commented 2 weeks ago

What would make your lives simpler? if the tag matches the version it would be better for you?

That would unlikely change a status quo of packagers dropping this suffix. Why does cargo version have to be included in cargo-c version?

lu-zero commented 2 weeks ago

Because cargo-c tracks cargo and semver allows adding that information that way as it is done in many other crates.

AMDmi3 commented 1 week ago

Because cargo-c tracks cargo

Why should it be expressed in the version?

semver allows adding that information that way

That feature of semver introduces ambiguity to your codebase versioning and is not compatible with most downstream consumers.

lu-zero commented 1 week ago

cargo-c is no different from:

Downstreams are right in omitting it if they see it fit, at least that's how I'm reading the spec:

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. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.

AMDmi3 commented 1 week ago

Could you please point me to where it's cited from?

lu-zero commented 1 week ago

The https://semver.org/ website 10.

AMDmi3 commented 1 week ago

cargo-c is no different from

Others doing ugly stuff are never a reason to do ugly stuff yourself.

The https://semver.org/ website 10.

So it's just a semver peculiarity, not a rust/cargo policy, which doesn't justify its usage. And I still don't get which purpose it serves.

Why should it be expressed in the version?

Build metadata MUST be ignored when determining version precedence

This is fundamentally flawed. It allows to adds metadata which is not a version (a version which identifies a point in codebase history, and can be compared to determine which release is newer) to a version, breaking all utilities which work with versions (such as repology, any other new release checkers, dependency updaters, vulnerability reporters etc.), and this cannot be fixed by using special code for handling semver, because there's no knowing whether a specific project even uses semver.

lu-zero commented 1 week ago

Well, at least you know for sure that if it is a rust package it does use semver so you can simply drop the semver metadata bit as you ingest the cargo metadata :)

AMDmi3 commented 1 week ago

There's no way to do that reliably, as for instance

Repositories may pull this data in, as in this case, and version normalization have to be performed on repositories as well, and that's not possible in general as not all repositories support + sign in versions, so they will have metadata normalized their way, and we'll need to handle it manually in each specific case.
It's not always known that the package is rust crate, as it may not be distributed through crates.io or may not be merged with crates.io project yet.
There are cases even on crates.io where versions only differ by +suffix. I have no idea how that should be handled.

But it still can be done to some extent, however I need to decide how to handle it the best way, as there are options (strip suffix everywhere, strip suffix for crates.io and treat as invalid in repositories, treat as invalid everywhere, allow both schemes, etc). So could you please explain why unrelated metadata is needed in the version?

mtelka commented 1 week ago

But it still can be done to some extent, however I need to decide how to handle it the best way, as there are options (strip suffix everywhere, strip suffix for crates.io and treat as invalid in repositories, treat as invalid everywhere, allow both schemes, etc). So could you please explain why unrelated metadata is needed in the version?

@AMDmi3 please do not treat the suffix as invalid in repositories because crates.io does not allow to access the crate version without the suffix and so we (the distribution - OpenIndiana in this case) use the full version as listed at crates.io as the package version too. This is both to simplify our packaging process and to do not mangle the version for our users to avoid confusion.

We simply use anything that the upstream chose for their version number as our version number too. Either it is 0.10.5+cargo-0.83.0 as in this case, or 9.9p1 for OpenSSH, or 1.001001 for Perl modules, or 1.2.2.post1 for Python projects, or anything else. This problem should be solved upstream and cannot by solved by distributions reliably. If we would try to do so, then all distributions would need to agree what is the right conversion from project's version to downstream version. And that won't work, obviously.

repology / repology-rules

`cargo-c` version `0.10.5+cargo-0.83.0` is not detected as the latest version #879