We are somewhat moving away from the cci.DATE versioning schema.
As a leftover from Conan 1 days, when coming up with such schema, not much attention was given to how it would work with version ranges.
The current situation is that any recipe that both defines a release version and a cci. version will think that the cci releases are newer because of how we interpret and expand semver ordering.
The new schema ensures this will not happen going forward.
There are 2 pain points that are left untouched as of yet:
Conan 1 semver parser does not support more than 4 digits as part of the version, so we either have to change this to 0.cci.date which is unconvinient
(Some libraries like to make the first release as 0.x, which would put us back with the same problem!), or wait to implement this until Conan 1 is deprecated in CCI
Old cci versions still will not work. We might think about how we can better tackle this when we deprecate Conan 1 too
We are somewhat moving away from the
cci.DATEversioning schema.As a leftover from Conan 1 days, when coming up with such schema, not much attention was given to how it would work with version ranges.
The current situation is that any recipe that both defines a release version and a cci. version will think that the cci releases are newer because of how we interpret and expand semver ordering.
The new schema ensures this will not happen going forward.
There are 2 pain points that are left untouched as of yet:
0.cci.datewhich is unconvinient (Some libraries like to make the first release as 0.x, which would put us back with the same problem!), or wait to implement this until Conan 1 is deprecated in CCI