Open SpaceIm opened 2 years ago
I totally agree with this issue. Maintainer of the recipe should have possibility to set version order. +1 from me.
@SpaceIm if implemented this only affects display order at Conan center website, right? Conan client cannot benefit from it?
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).
...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:
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.
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;
}
I would like to collect here patterns we can see in libraries that are contributed to ConanCenter:
x.y.z
<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
x.y
openssl
with x.y.z<letter>
abseil
with <date>.x
cci.<date>
and semver x.y.z
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
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 acci.yyyymmdd
, it's over it will always be the latest version for conan.io), and order is:It's completely wrong,
1.3.204.0
is the last version, and order should be: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.