Related to Please be mindful of version bounds and semantic versioning when tagging your packages - #86 by Tamas_Papp, but I would like to put this as an independent question.
If I understand correctly, the information about compatibility of registered package versions exists both in the Project.toml of the corresponding commits in the package’s repo, and in its Compat.toml file in the registry.
How do those two files interact with the package manager when you Pkg.add or Pkg.dev, etc.? Are both used? And what would happen if the information in one of them is not coherent with the other?
The underlying reason of making this question is my thinking that having both files might be a way to settle (at least partially) the conflict of required upper bounds in [compat]. If the Compat.toml of the registry is the prevailing information used to decide what versions install when you add from the registry, the package maintainer could keep an unbounded [compat] section in its Project.toml, while Compat.toml has the required bounds to ensure that the version installed from the registry has a safe combination of dependencies.
This would require the registry’s bot to know what are the suitable upper bounds of dependencies to put in Compat.toml. They could be taken from the Project.toml of the submitted commit if given, and otherwise set to the latest registered versions. Such “guessing” could be conditioned to the existence of successful CI checks.
If this makes sense, package authors could relax the maintenance of their packages. The registry could also update automatically the Compat.toml files from time to time (e.g. on a scheduled basis, or when major Julia versions are released, or…). To make this in a safer way, an issue could be submitted to the package repos, requesting them to update their [compat] sections or re-trigger the CI to verify that the package tests pass with the latest allowed dependencies.
And if this doesn’t make sense… well, just forget this post.