libjulia: New global variable supported_julia_versions

[eschnett]

[skip ci]

[giordano]

@barche @benlorenz @fingolfin @lgoettgens are you happy with this?

[lgoettgens]

@eschnett could you maybe give some motivation for this? I don't quite understand what this new variable is supposed to mean and how it is intended to be used.
In particular, the comment states that the new variable contains the versions we want to build for by default, but there is no such change later down in the file where the build_tarballs is called.

[benlorenz]

I guess one could then use supported_julia_versions instead of the julia_versions.

Various packages already use the default julia_version with some filter to get those with e.g. version >= 1.10.

It wont help much (for dropping old versions) unless we somehow get people to adopt this, a while ago I tried to collect packages which do still support older julia versions:
#11683 (comment)

[eschnett]

Yes, that is the intended use. I'd be happy to switch the value of julia_versions instead, introducing a new variable julia_versions_including_outdated_versions. (Name to be improved.) This would automatically "update" all downstream packages.

[lgoettgens]

Both of the options only change what julia versions dependents of libjulia build for (either opt-in or opt-out). But I don't see how this eventually allows us to drop the libjulia builds for these julia versions from the libjulia recipe.

Of course one (maybe a bit too drastic) version would be to replace julia_versions by the filtered list and still use that for future libjulia_jll builds. I that case, I don't think we would even need julia_versions_including_outdated_versions anymore.

[lgoettgens]

I guess one could then use supported_julia_versions instead of the julia_versions.

Would supported_julia_versions drop the 1.11 entry once 1.12 is released as then 1.11 is no longer officially supported? And I wouldn't think that nightly would count as that. I understand the intention, but maybe the name is a bit misleading

[barche]

It might be better to have a function instead of a variable, something like julia_versions_from(v"1.10") ? I think that would better fit the objective of avoiding to have everyone write their own filtering implementation.

[giordano]

I'd tend to agree with Bart. Also, "supported" bit is misleading, builds are available and would work, it's just that for most cases it may not be worth it having builds all the way down to v1.6, also because that just generate a ginormous number of artifacts (which also slows down the infrastructure here in Yggdrasil).

[eschnett]

The point is to move the constant v"1.10" from all the build scripts to a single place.

[lgoettgens]

The point is to move the constant v"1.10" from all the build scripts to a single place.

You are right that this would get rid of the constant in

Yggdrasil/L/libsingular_julia/build_tarballs.jl

Line 37 in 4235d32

filter!(>=(v"1.10"), julia_versions)

. But it is also present in

Yggdrasil/L/libsingular_julia/build_tarballs.jl

Line 67 in 4235d32

preferred_gcc_version=v"8", julia_compat="1.10")

(both examples from a random libjulia dependent).
And since it appears in two places in the recipe, I would prefer to not move one of these to a different file. In particular, if we at some future point adapt this common definition, and someone rebuilds without changing the julia_compat in their recipe, they will get a confusing to use package (as it is missing some artifacts).

[fingolfin]

So if one wants to centralize, the alternative would be to have a global const minimal_supported_julia_version = v"1.10" (or so). Deriving the string for julia_compat then would also be possible.

I guess one then would only introduce that, and adjust the filter statements and julia_compat kwargs accordingly?

[barche]

I think there are two problems to solve: one is how to allow individual package maintainers to select applicable versions, the other is how to bump the minimal version for the entire ecosystem. I don’t think there is a consensus on the latter, e.g libcxxwrap-julia still is on 1.6.

[eschnett]

The first ("allow individual package maintainers to select applicable versions") is not a problem. You can just filter the versions in the package's build script. I'm trying to address the second here, answering the question: "Please give me a list of versions for which I should build my package, if I don't want to think too hard myself about this question."

[barche]

"Please give me a list of versions for which I should build my package, if I don't want to think too hard myself about this question."

I always thought julia_versions was that. I think it's currently a bit of a strange situation with the LTS having moved from 1.6 to 1.10, and someone should bite the bullet on when to drop everything before 1.10. I would be OK with that. Support for versions older than 1.6 was also dropped a few months after 1.7 came out if I interpret the git history correctly.

[eschnett]

Very good then, julia_versions it is. (I also think that we can switch this variable to 1.10.)