[conan.io/center] Versions may not be displayed in the "correct" order

[SpaceIm]

Sometimes, recipes mix different versioning, either because library author has change versioning or because we have both cci.yyyymmdd and regular versions. As a result, looking at versions in https://conan.io/center, it's not obvious for users what is the last version.

For example spirv-headers.

In https://conan.io/center (https://conan.io/center/spirv-headers), it claims that cci.20211010 is the last version (yes as soon as you have a cci.yyyymmdd, it's over it will always be the latest version for conan.io), and order is:

1.2.198.0
1.3.204.0
1.5.1
1.5.3
1.5.4
cci.20210414
cci.20210616
cci.20210811
cci.20211010

It's completely wrong, 1.3.204.0 is the last version, and order should be:

1.5.1
1.5.3
1.5.4
cci.20210414
cci.20210616
cci.20210811
cci.20211010
1.2.198.0
1.3.204.0

Because there is nothing obvious in this order, I suggest to enforce a specific order in config.yml so that https://conan.io/center can rely on it.

[igormironchik]

I totally agree with this issue. Maintainer of the recipe should have possibility to set version order. +1 from me.

[db4]

@SpaceIm if implemented this only affects display order at Conan center website, right? Conan client cannot benefit from it?

[SSE4]

I personally believe it's something to be implemented in the client, as a first-class feature. a recipe should be able to provide its own comparator for the versions, as it knows the correct order. if order differs from default (semver), conan will not be able to deduce that, and there should be the way to specify it from the outside. that way, not only conan.io/center website will benefit, but it may allow using version ranges with arbitrary libraries, as well as other cool features on top of version comparison (get the last version, bisect, and so on).

[jgsogo]

...and it can get really complex with libraries using two sets of versions https://github.com/conan-io/conan-center-index/pull/9544

Of course, nothing generic would work, and someone/somewhere needs to take care of it in a way that people can contribute other weird versioning schemas that will pop up from time to time. I see different proposals:

• Conan client: it would be a capability that can be improved with each new version. The main drawback I see is that there are some version schemas that are specific to CCI and there might be others specific to other centers.
• recipes: each recipe can encode how to deal with the versions of its own library, at least, the ones that are known at the moment when the recipe is written. Of course, in order to use it, it requires some implementation on the Conan side. The main drawback I see here is that when you have a bunch of versions and you want to know which one is the latest, you need to use the latest rrev from the latest recipe version to run the ordering (only the latest knows 100% sure about all the others). It's a bit of a chicken-and-egg problem.
• 3rd party cci-versions library: it can be a python package (easy to use from Conan) or a C++ library (easy to use in the web backend). A public repository where we can implement the required logic (if (name) else if (name) else if (name) else if... else 🙈 ), release new versions with enhanced logic, and just use it. ^{_{Of course this library should use standard versioning schema, hahaha.}}

I would say that first we need to open this issue on the Conan client repository and get some feedback from that side. Then, we can think about something cci-specific if needed.

[jgsogo]

I don't want to forget about something that @SSE4 has suggested just some minutes ago: versioning_schema.

To provide an attribute in the recipes (maybe config.yml if it is specific to CCI) that declares the versioning schema used by the library (semver, cci.date,...)

Then, the logic in that library could implement something like:

// Check first if there is anything custom for that name
if (name == "xxxx") {
   return custom::compareXXX;
} else if (name == "yyyy") {
   return custom::compareYYY;
}

// Now use the versioning scheme
if (versioning_schema == "semver") {
   return semverCompare;
} else if (versioning_schema == "cci.date") {
   return cciDateCompare;
} else if (....) {
   ...
} else {
   return lexicographic;
}

[jgsogo]

I would like to collect here patterns we can see in libraries that are contributed to ConanCenter:

• regular semver x.y.z
• regular date <date> like 20211225
• spirv-headers mixes x.y.z with x.y.z.w and cci.<date>.
• glslang Two series of versioning schemas in parallel: x.y.z and x.y.z.w
• semver-like with 2 tokens x.y
• openssl with x.y.z<letter>
• abseil with <date>.x
• cci.<date> and semver x.y.z

[SSE4]

• diligent-core mixes x.y.z and API<date>
• android-ndk with r<number>[<letter>]
• cppcommon with x.y.z.w
• folly with <year>.<month>.<day>.w
• hana has version boost-1.74.0 in addition to x.y.z

packages.txt