Streamline retroactive compat bounds adjustment

[LilithHafner]

• Document the compatibility specification format
  • https://pkgdocs.julialang.org/v1/registries/#Registry-Compat.toml
• Add CI checks to verify that specifications are properly formatted (and only run checks on edited files)
  • Registry consistency tests: In Compat.toml, make sure that each compat spec is a valid registry compat spec RegistryCI.jl#575
• Add instructions for retroactive compat bounds adjustment to README and link exemplary merged PRs
• Add some highly automated @JuliaRegistrator set_compat_bounds(...) invocation
  • Moved to separate issue: Feature request: Add some highly automated @JuliaRegistrator set_compat_bounds(...) invocation Registrator.jl#436

(the 4th item is likely excessive)

[felixcremer]

The compat format is described here: https://pkgdocs.julialang.org/v1/registries/#Registry-Compat.toml

[DilumAluthge]

• Document the compatibility specification format

https://pkgdocs.julialang.org/v1/registries/#Registry-Compat.toml

[DilumAluthge]

• Add some highly automated @JuliaRegistrator set_compat_bounds(...) invocation

Let's move this to a separate issue on the Registrator.jl repo: JuliaRegistries/Registrator.jl#436

[DilumAluthge]

• Add CI checks to verify that specifications are properly formatted (and only run checks on edited files)

JuliaRegistries/RegistryCI.jl#575

[goerz]

Could someone elaborate on what “ retroactive compat bounds adjustment” means, exactly? How would it not break reproducibility? (Cf #119607 (comment))

I wasn't aware that we allow the compat bounds of releases to be changed retroactively, e.g., in #115069. Are there guidelines on how/when to do this? Maybe I'm just not thinking this through correctly.

[LilithHafner]

Could someone elaborate on what “ retroactive compat bounds adjustment” means, exactly?

It's exactly what it says on the tin. Changing the compat bounds of a released version of a package after its release. This is almost always a reduction in declared compatibility (an increase can be declared by releasing a new version with wider compat bounds). The reduction is often done to indicate incompatibility with a version of a different package (or Julia) that did not exist at the time the original was registered. This does not alter the behavior of the package at all, simply informs Pkg (or any other Julia package manager you might be using) that this version of the registered package is not compatible with some versions of some other packages.

How would it not break reproducibility?

Yanked packages can still be instantiated from manifests and I would hope the same is true for packages with unsatisfied compat bounds. If you're going for reproducibility using a Manifest.toml, it should continue to work; if you're going for reproducibility and only have Project.toml, then you may end up with different—symver-compatible—versions of any packages you depend on, even without retroactive compat bounds adjustment.

Are there guidelines on how/when to do this?

I think it's appropriate to adjust compat bounds as an alternative to yanking in the second category of yank candidates on the readme:

That special category is when the compat bounds have been set too wide. i.e. say v2.10.0 was released using a feature not on julia v1.6 but the compat entry for julia was not raised in the release.

[goerz]

Yanked packages can still be instantiated from manifests and I would hope the same is true for packages with unsatisfied compat bounds

That's the part that wasn't obvious to me. If that works, all should be fine. And I guess we've been doing these adjustments routinely, given that there's a compat fix tag, and nothing seems to have blown up 😉

I'm certainly learning a lot of new things about the registry these last couple of days!