[conan.io/center] flux still has cci.20240115 as the default version on ConanCenter when it already as 0.4.0

[SidneyCogdill]

What is your problem/feature request?

https://conan.io/center/recipes/flux has version cci.20240115.

The newer version 0.4.0 is merged, and visible at https://conan.io/center/recipes/flux?version=0.4.0, however if you search on ConanCenter, it defaults to the older version.

Maybe I've done something wrong that causes the page to not update properly.

[SidneyCogdill]

mp-units was updated to 2.4.0 yesterday and the newer version is already the default at https://conan.io/center/recipes/mp-units so I think the issue isn't that I haven't waited long enough.

[jcar87]

Apologies for this - this is part of the migration to our new CI pipeline and deprecation path for COnan 1.x

From my earlier comment -
#25845 (comment)

conan remote update --url https://center2.conan.io conancenter

The legacy repository is no longer updated (but still up and running). This will be all announced today more widely

[SidneyCogdill]

I think that's a different issue.

My issue is not that "The newer version is listed on the website, but can't be installed by conan".

My issue is: The new version is listed on the website, but the website defaults to a older version that the users shouldn't be using over the new version.

[jcar87]

I see - this is a result of the old versioning scheme that we gave to projects that didn't have a versioning scheme. Once they do - unfortunately cci comes "ahead" as more recent as it is a lexicographic sort.

For new cases like this, we are making sure that "custom" versions are 0.0.0.cci.date, see https://github.com/jcar87/conan-center-index/blob/188bfd8aa82de847cf1fdeb9751a0aa95c6f8dd0/docs/adding_packages/conanfile_attributes.md#conancenter-specific-releases-format

Such that in the event of an actual version scheme being made available - the custom scheme is always the oldest possible.

Unfortunately I'm not sure there is much we can do about this: we can't remove versions from the remote because they may already be in use, and even if we had the website sort differently, flux/[*] would still resolve to the cci version.

[SidneyCogdill]

Conan repository already has the v1 and v2 split. Can't we just remove the cci version of flux from v2 and keep it as is for v1? Anyone not wanting to change can stay in v1.

[jcar87]

That is completely unrelated I'm afraid - if flux/cci.20240115 was ever available for Conan 2, removing it would cause issues. We try very hard to not break users, and to ensure reproducibility - people can change and update to the new one, but we want to retain their ability to roll back to the earlier version.

[tcbrindle]

So just to be clear -- is the default version of Flux on Conan going to remain an ancient git snapshot forever, no matter how many future releases of the library I might do?

Because that seems pretty bad.

[jcar87]

Generally, with a Conan dependency there is no "default" version - the solver will bring in what is requested, and in most cases these tend to be actual versions, e.g. for boost most users do self.requires("boost/1.84.0"), or a relatively narrow version range, you can look at the ones we've been using Conan Center here: https://github.com/conan-io/conan-center-index/blob/master/docs/adding_packages/dependencies.md#version-ranges

It is true that if a user requests the most unconstrained range flux/[*] - then yes, it will resolve to the wrong version. However, we tend to be conservative when it comes to the unconstrained range, since very (very) few libraries actually provide that level of indefinite backwards compatibility. On the other hand, unless a library explicitly advertises these - we wouldn't expect users to request the unconstrained range for libraries that only have 0.x releases - generally these tend to indicate that the API is not stable and may change at any time, as per https://semver.org/#spec-item-4, although obviously each library main follow its own conventions.

We can mark the cci snapshop as deprecated and make that fail with a warning - pointing users to a recent version. The "earlier" recipe revisions for the same version will still work, but newly ones wouldn't. We can also look into reordering what's displayed on the website if that helps.

I wouldn't say this is a forever issue as well - it's perfectly valid for Conan to support the use case where a library may have different versioning schemes across time, and need to reorder them in a way that is non-obvious - the added complication in our case is that this might involve making modifications to the server side behaviour of Conan remotes

[tcbrindle]

Thanks for the info @jcar87. If requesting unconstrained versions (assuming you'll get the most recent) is a rare thing to do in the Conan world then I guess this isn't as bad as I feared -- I'll add a note to the Flux README advising against using the wildcard form, which will hopefully put users on the right path.