Use the published `versions.json` instead of listing versions in source code?

[KristofferC]

Instead of hardcoding version information in the build file:

https://github.com/JuliaLang/juliaup/blob/623684d248c50a34e912ff0223bdfd154df4f0d5/build.rs#L23-L52

it perhaps makes sense to use the published https://julialang-s3.julialang.org/bin/versions.json file (that among other things is used for CI). That would decouple the version information from the juliaup executable which feels like a good idea.

There is, however, no way to determine which is the latest LTS from that file AFAIU. That could be hardcoded to be 1.0.x for now (where the latest such version from the file is used).

[PallHaraldsson]

no way to determine which is the latest LTS from that file AFAIU. That could be hardcoded to be 1.0.x for now

That's of course no longer the case, so you want to have Julia 1.6.4 for LTS, that fixes a security issue. It's a question if you want to warn (or block?) against any older version.

[davidanthoff]

I looked into this in a bit more detail, and at the moment the official versions.json is missing a fair number of specific archives that we need. I didn't look through everything, but minimally this:

• For Mac, it only lists the .dmg files, not the .tar.gz files
• For Windows, it only lists the .zip files, not the .tar.gz version

It is not clear to me how this could be fixed without breaking lots of stuff. Presumably a lot of existing downstream code relies on the fact that there is only ever one entry in the files list as archive for a given triplet value, so just adding another entry to files is probably not a good idea. Also, even if that wouldn't break lots of things, one would then have to look at file extensions in the URL to figure out which entry uses what kind of archive, which also seems like a bad design.

I guess maybe one option would be to allow a value of targzarchive in the kind field, and that add lots of new entries with that? But that of course also has the potential to break downstream stuff...

CCing a random list of folks that might have input on this @staticfloat, @SaschaMann, @ararslan

[SaschaMann]

I wasn't even aware those existed. The main thing we can do without breaking downstream stuff is adding keys, so my initial thought was that we could add an alternates: [] key to the archives and perhaps list the others in there? Though I have to say that feels like a bodge.

[davidanthoff]

Another option would be that we ignore everything in files, and just use the list of versions that we can get from versions.json, and continue to construct download URLs ourselves... That might actually be the easiest short-term solution.

[uncomfyhalomacro]

I just noticed, in the https://julialang-s3.julialang.org/bin/versions.json

Does "stable" mean a "stable" release?

just asking a question because i was thinking of a solution to avoid hardcoding because i want that even at lower juliaup versions, it can still update to the latest stable release or install another version if available but it seems there is no solution yet

[LilithHafner]

Don't want to step on @davidanthoff's toes (c.f. https://github.com/JuliaLang/juliaup/issues/326#issuecomment-1190797353)

[IanButterworth]

For those following here, https://github.com/JuliaLang/juliaup/pull/417 seems to implement this