Automatic compat for stdlibs is problematic

[GunnarFarneback]

If you for example run Julia 1.11 and Pkg.add Random to a package, this automatically adds a compat entry with 1.11 compat (since Random is an stdlib with version following Julia). As a consequence the package becomes incompatible with Julia 1.10 and older, as can be seen in this example (most output removed for clarity):

$ julia +1.11
(@v1.11) pkg> generate TestCompat
(@v1.11) pkg> activate TestCompat
(TestCompat) pkg> add Random
julia> mkdir("TestCompat/test")
julia> write("TestCompat/test/runtests.jl", "using Random")
(TestCompat) pkg> test
     Testing TestCompat tests passed 

$ julia +1.10 --project=TestCompat
(TestCompat) pkg> test
ERROR: Unsatisfiable requirements detected for package Random [9a3f8284]:
 Random [9a3f8284] log:
 ├─possible versions are: 1.10.10 or uninstalled (package in sysimage!)
 └─restricted to versions 1.11.0-1 by project [708c9892] — no versions left
   └─project [708c9892] log:
     ├─possible versions are: 0.0.0 or uninstalled
     └─project [708c9892] is fixed to version 0.0.0

This is problematic and has caused real problems where people have registered packages in General which have worked on the latest Julia version but not on older versions, e.g. the 1.10 LTS, within the declared Julia compat. It is also generally confusing for people who add an stdlib and it works fine locally, but fails in CI, which happens to run an older Julia version.

Either the automatic compat should be disabled for stdlibs or add a safe entry, if that is possible.

[DilumAluthge]

I think we should just disable this for stdlibs.

[IanButterworth]

Be aware that General registration will fail without it.

What about just setting it to the current major? Is that safe across all stdlibs?

[DilumAluthge]

Be aware that General registration will fail without it.

We've disabled that AutoMerge requirement for the time being, because it was causing too much headache: JuliaRegistries/RegistryCI.jl#540

What about just setting it to the current major? Is that safe across all stdlibs?

Still has the issue of 0.0.0 on old Julia versions. And doesn't address the problematic 0.7 of SHA.

IMO, if we are going to add compat entries for stdlibs, the only safe thing to do is:

1. SHA: < 0.0.1, 0.7, 1
2. All other stdlibs: < 0.0.1, 1

[DilumAluthge]

But I think it'd be easier to omit compat entries entirely for stdlibs, given that the AutoMerge requirement is disabled.

[vchuravy]

But I think it'd be easier to omit compat entries entirely for stdlibs, given that the AutoMerge requirement is disabled.

I don't have time to work on it, but I think as a long-term goal we should go back to having that requirement enabled. So I would prefer figuring this out properly.

[DilumAluthge]

In that case, I think we need to do what I wrote above.

1. SHA: < 0.0.1, 0.7, 1
2. All other stdlibs: < 0.0.1, 1

Otherwise, SHA causes problems, and all stdlibs cause problems on old Julia versions.

[IanButterworth]

Are those incantations still required for 1.10+? Or are we being more conservative than I think we need to be and protecting against bad pre-1.10 versioning?

[DilumAluthge]

Not required for Julia 1.10+.

But IMO, I feel pretty strongly that we shouldn't be going out of our way to break older Julia versions, even if they are technically "unsupported". Especially in this case, where it's so easy to either:

1. Not add automatic compat for stdlibs.
2. Add automatic compat, but add it as I described above.

Those options are both pretty easy, so I don't think we should break old Julia versions if we don't need to.

[ericphanson]

SHA still doesn't have a 1.0 release: https://github.com/JuliaCrypto/SHA.jl/blob/89b80b95764c5c305ca17310fc9a62d38145cb29/Project.toml#L4

[IanButterworth]

Doesn't fix our immediate issues but seems logical to do:
JuliaWeb/LibCURL.jl#118
JuliaCrypto/SHA.jl#125

[DilumAluthge]

SHA still doesn't have a 1.0 release

FWIW, on Julia 1.0.5, Julia thinks the version of SHA is 1.0.5 (matching the Julia version).

To reproduce, create this Project.toml file:

[deps]
SHA = "ea8e919c-243c-51af-8825-aaa63cd721ce"

[compat]
SHA = "0.6, 0.7"

And then try to instantiate that project with Julia 1.0.5. You'll get the following error:

(MyProjectName) pkg> instantiate
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package SHA [ea8e919c]:
 SHA [ea8e919c] log:
 ├─possible versions are: 1.0.5 or uninstalled
 └─restricted to versions [0.6.0-0.6, 0.7.0-0.7] by an explicit requirement — no versions left

So it seems that Julia 1.0.5 thinks that the version number for SHA.jl is SHA v1.0.5. That's why I think the SHA compat entry needs to include 1, to avoid breaking things.

I think this holds for some other Julia versions too, but I didn't have time to check.

[IanButterworth]

I really think the healthy thing to do is to forget about pre-1.10 julia versions on this specific issue.
It could make this really straightforward and easy to explain.

Just SHA and LibCURL needing something different than "1" AFAIU.

But that's just my two-cents.