I definitely want things to eventually just depend on versions.json and get rid of all manual steps. I think we want to get there in two phases:
Some changes to versions.json will always require release of a new complete version of juliaup, i.e. pushing of a new version to the store, the various package managers etc. In particular, whenever the release version of Julia changes, that is the case, because juliaup internally ships/bundles that particular build. I think to automate this more, we probably need some way that an update to versions.json triggers a GitHub workflow in the juliaup repo, and that workflow then prepares a PR for a new version of juliaup or something like that. I could see a scenario where things are fully automated with no user input for this, but maybe that is further down the road, for now it would just be great if there was something automatically kicked off.
A more refined second solution would allow the juliaup client to download new version info without updating juliaup itself. This would be useful whenever a new Julia build is released that is not the main released version at the moment, i.e. new LTS versions or prerelease builds. It would also be especially useful down the road if we succeed in putting juliaup into say the default Ubuntu package manger that apt interacts with, where we won’t be able to update juliaup regularly. This entire scenario is much more complicated, though. We need to deal with things like download size, the size of the version DB on disc (to make sure we don’t spend too much time checking things from a large JSON file whenever julia launches), the stability of the schema of things, handling race conditions on the update side of the version DB file, the interaction of updates to the versions.json file with updates to juliaup itself etc. An earlier version of juliaup actually had all of this implemented, but it was too brittle, so I removed it until we can implement a more robust solution.
I think for now just having the first option would already be great. Having the second option would at the moment be a nice to have things, but wouldn’t actually make the end-user experience that different, so I’m tempted to wait a bit with that. I do think we really need the second part if we get serious about getting juliaup into slower moving package managers, though…