Support "latest" in .tool-versions

[cj81499]

Is your feature request related to a problem? Please describe

I would like the default version of various tools on my system to always be the latest available version.

Describe the proposed solution

I propose adding support for the special value "latest" within .tool-versions files. It would evaluate to the latest available version for that particular tool.

One concern I see with this is the need to frequently check for updates to a given tool. To avoid this, available versions of a tool could be cached for some duration. Ideally, this duration would be configurable by the user.

Describe similar asdf features and why they are not sufficient

Currently, I can run asdf global my-tool latest, and the version in my global settings (~/.tool-versions) will be set to the latest available version. However, when a new version of the tool is released, the default remains set to whatever value latest evaluated to when I last ran the command.

Describe other workarounds you've considered

I've considered changing my .zshrc file to check for updates at shell launch, but this obviously has a significant negative impact on shell startup time.

Another possible workaround is a cron job that would run a script to check for updates. This would work, but I ultimately feel this functionality may be useful enough to justify being built-in.

[jthegedus]

Updating your global deps is something you can script and run in user space, similar to most system package managers where installation of updates is opt-in on an update by update basis (note that asdf is not itself a package manager).

We do not want to support this type of feature in asdf. Here is an explanation from another discussion:

Special versions like latest are resolved at the time the asdf command specifying them is run and are not permitted to in .tool-versions because of the nondeterminism they would introduce. We don't want to allow any variability in versions specified in any of the version files that asdf supports because we want asdf to be deterministic. We don't want a new version release to accidentally pull the rug out from under someone because they had specified a shorthand version or version range. This constraint allows us to provide stronger guarantees about asdf behavior.
-@Stratus3D in asdf-vm/asdf-nodejs#235

@Stratus3D I will PR an FAQ item for this issue so we can link to it in future. And and also propose an update to the legacy versions file support docs so we can link to it in discussions like asdf-vm/asdf-nodejs#235.

[Stratus3D]

@Stratus3D I will PR an FAQ item for this issue so we can link to it in future. And and also propose an update to the legacy versions file support docs so we can link to it in discussions like asdf-vm/asdf-nodejs#235.

Thanks, sounds good!

[rtyley]

We don't want to allow any variability in versions specified in any of the version files that asdf supports because we want asdf to be deterministic.

I only recently found this discussion, and I can see that maintainers of asdf have taken a very clear line on this position. I raised this PR:

• feat: Enable use of latest: in .tool-versions files #1793

...before I found this discussion, and I realise now that it's unlikely to get merged, but I still would like to ask if there's any room for allowing users to express their preferences on variability.

Given the range of tools/ecosystems that asdf supports, at least some of them- like Java LTS versions - allow only security fixes when minor/patch version increments occur. Our experience at the Guardian, over nearly 2 decades of using the JVM, is that if a program runs correctly under a specific version of the Java runtime, it can be relied upon to run correctly under any later version of that runtime with the same major version number.

This means that for projects in those ecosystems, there is little incentive to pin to fully-specified versions like 21.0.5.11.1, and in fact there are downsides - over time, developers will default to using older, unpatched versions of Java, unless they are assiduous in continually updating the contents of the .tool-versions file, or have tooling devoted to doing so.

At the Guardian we have several hundred projects that run on the Java platform, and due to our security obligations we generally want to be running under the latest security-patched version of the Java runtime that matches our major-version requirement. We love asdf as a tool, and like that the .tool-versions file can become a source-of-truth documenting which version of Java a project uses, but we don't want to have to commit fully-specified version numbers like 21.0.5.11.1 to source control, or set up tooling to increment those version numbers across hundreds of repositories.

I think there are at least some users who would accept some variability in exchange for staying up-to-date, and it's worth considering whether it's reasonable to allow them to select that. In terms of the existing latest: syntax already used by asdf, the constraint can be made quite tight (eg. java latest:corretto-21.0.5) or looser (eg. java latest:corretto-21) - so the choice of how much variation they want to accept can be expressed by the user.