[docs] Why are version rangers not allowed?

[prince-chrismc]

Docs!

I noticed this in some recent PR and was not able to find it documented. I was not able to find the pass conversations (we make too many PRs - good problems) so I went off memory.

Feedback welcomed!

[uilianries]

Almost good to go.

[conan-center-bot]

Updating docs!

[uilianries]

LGTM Thank you very much!

[garethsb]

Good to have this in the docs for sure! What does package version mean in "may resolve to a different package version"? If it's just version in the sense that the binary might be slightly different maybe a different phrase would be clearer. If it's about generated metadata e.g. package id, would build requirement versions affect that? If not, a different justification is required for prohibiting version ranges for e.g. CMake.

[SSE4]

Good to have this in the docs for sure! What does package version mean in "may resolve to a different package version"? If it's just version in the sense that the binary might be slightly different maybe a different phrase would be clearer. If it's about generated metadata e.g. package id, would build requirement versions affect that? If not, a different justification is required for prohibiting version ranges for e.g. CMake.

a range like boost/[>1.76.0] may resolve into boost/1.78.0 today, but it also may resolve into boost/1.79.0 tomorrow, as soon as new version is released. that might cause many troubles for users, as well as for CI systems. imagine you're running Windows and Linux builds in parallel, and one of them gets old version, and another one gets a new version. probably, not something you would desire out of the box, right?

[prince-chrismc]

What does package version mean in "may resolve to a different package version"?

It's really the version of the dependency you are trying to add. It's a superficial comment (from my lack of expertise)

If it's about generated metadata e.g. package id

That's an excellent question! I have no idea 😄 peaking at th docs its not obvious whats the affect on the package_id https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html#using-package-id-for-package-dependencies

UPDATE:

After some digging I found this conan-io/conan#8504 (comment)

package_id is always calculated on the resolved value, not the declared (and potentially dynamic) value.

would build requirement versions affect that?

I think it's more clear in Conan V2, https://docs.conan.io/en/latest/devtools/build_requires.html?highlight=package_id
My understand is no it should not

The old build_requirements sometimes were used to hide dependencies which made it misleading (and really confusing). I am not sure how it works today

[jgsogo]

Reproducibility and compatibility is a good reason to avoid version ranges in CCI, but not the only one. In fact, even if we fix a version, we still are using different recipe revisions when they are available... reproducibility is not possible without using lockfiles.

Another reason is the default package-id mode. It takes into account the major version of the requirements. With version ranges someone could declare xxxx/[>=1,<3.0.0] and the computed package id would be different depending on the version resolved of that requirement... which basically breaks the user experience of ConanCenter if you just try it and start getting missing binaries.

[jgsogo]

Anyway, this is a good note, we can improve it in the future 👍