Conan-center-index: [question] [docs] Rules about upgrading the requirements

[prince-chrismc]

Given that a recipe has many dependencies, it's very common that one of it's requirements can have a higher version available in CCI then whats written in the recipe.

For header only there is no issue as the requirement can be overridden by the consuming conanfile, however compiled libs may suffer from API/ABI incompatibilities. This makes resolving conflicts very painful when two graphs overlap. Typically we get stuck building the package locally.

Are we permitted to open PR's where the only change it to the version of a required dependency?

Ideally as a consumer, it's preferable to pull everything from CCI rather than building things locally.

[jgsogo]

Yes, the main problem is when there is a conflict because two graphs require a different version of some requirements. We would really want to avoid this situation, so it is perfectly ok to open a PR to upgrade only a requirement.

What else can be done?

• Can CCI trigger a job with every new version of a library (or daily), check for other libraries consuming it, modify the conanfile.py and submit a PR? Some challenges here:
  
  
  
  • _"Find other libraries consuming it"_: we store the reverse graph, but only for requirements that are consumed with the default option values. Probably this is good enough, getting a conflict after modifying a default option is not so painful (you would need to build from sources).
  
  
  • _"Modify the conanfile.py"_: probably a regex replace would work. It can fail if the requirement name/version is not written in plain text, but... 99% it will work.
  
  
  • What if the job fails because the new version is incompatible? Who fixes the PR? Better to have a failing PR than nothing.
  
  

• Can we have a set of _master_ versions and other recipes should require those ones?
  
  
  
  • It would be challenging to bump one of them and rebuild all affected packages
  
  
  • How to deal with consumers that need other versions than the _master_ one?
  
  

Any other alternative?

[SSE4]

let's try to illustrate the situation on the hypothetical example. for instance, we have a library boost, which did release 1.72.0. at the time of release, boost had a dependency on another library, named zlib, and the latest release of zlib was 1.2.11.
it means in conan we would have a relationship like: boost/1.72.0 -> zlib/1.2.11.
okay, we have conan packages for both boost and zlib. now imagine that zlib suddenly made a new release, e.g. 1.2.12. should we upgrade boost release 1.72.0 right away to reference new zlib release?
it might look that obvious decision is to upgrade, but is it really so simple?
when boost maintainers did 1.72.0 release they run their regression tests with zlib 1.2.11, they tested various configurations (different compiler versions, operations systems, etc.) to ensure stability.
in conan we don't run so complete testing matrix, we only ensure that packages successfully build and pass simple test package. we never run test suites, and we never run the same set of supported configurations.
the same probably applies to every package.
I understand zlib example might be not so illustrative, as it's pretty stable and has a very stable interface, but in general - does it mean we always have to keep these references on bleeding edge to ensure there are no conflicts?

[uilianries]

Most of projects don't use a specific version for dependencies, it's hard for us tracking it. Indeed should reasonable keeping them aligned due the compatibility, but would need to check which version the author used, the latest version available when that release was made (by date)?

[SSE4]

@uilianries yes, there a projects like that. on the opposite side, there are cases then versions of dependencies are very hard requirements. for instance, your favorite protobuf - in case the project includes sources generated with protoc, it will need to link with the same version of protobuf, as generated sources contain hard version check.

[prince-chrismc]

My particular pain is fmt, which has a very aggressive release cycle, much more than it's dependents. Juggling 4 projects which require it is a growing pain. Version 6.0, 6.2, and 7.0 are requirements but all support 7.0 since they are not impacted by the API changes.

I would have to agree that automatically upgrading the requirements would be a sticky situation. To add to SSE$'s points, some recipes require a different version depending on the version (but these could be changed).

I have to test my code base when I changing dependencies, I may submit a few PRs after I am confident there's no issue. There will have to be a case by case review.

Would it be possible for the bot to fill an issue that shows all the conflicts?

[SpaceIm]

Auto updating recipes doesn't scale. What about recipes with a lot of dependencies (and big binaries)?
Look at GDAL. Do you really want to create another revision each time one of its many dependencies release a new version?
I think that CCI recipes should support version range, and eventually a "preferred" version if reproducibility is an issue (but a lock file should be what ensure reproducibility, not specific hardcoded version in recipes).
Consumers lose a lot of information without version range, they have to figure out themself compatible versions, while it is basically what a package manager should provide.