Commits on Oct 22, 2024

1. feat: Enable use of latest: in .tool-versions files …

   This change enables `asdf`'s existing latest-version-resolution
   functionality within the `.tool-versions` file itself. Rather than
   having to have a `.tool-versions` file that contains a full version
   number:
   
   ```
   java corretto-21.0.5.11.1
   ```
   
   ...you can now use the same `latest:` syntax that is already available
   in the `local` & `global` commands, ie:
   
   ```
   java latest:corretto-21
   ```
   
   ### Use case
   
   For many tool/runtime ecosystems (eg Java), if a program runs correctly under
   a specific version of that runtime, it can generally be relied on to run
   correctly under any _later_ version of that runtime with the same major version
   number (eg if a project runs under Corretto Java 21.0.5.11.1, it will run on
   any _later_ version of Corretto Java 21).
   
   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 those hundreds of repositories.
   
   Allowing the use of `latest:` in the `.tool-versions` file means that we
   don't need to continually update those `.tool-versions` files. It also
   partially addresses some of the needs raised by asdf-vm#1736,
   though this solution uses the existing `asdf` version-resolution functionality,
   rather than adopting the version requirements system used in nodejs.
   
   ### Implementation
   
   A new `resolve_version_spec()` function has been extracted from the
   existing `version_command()` function. This takes a version-spec string,
   like `latest:corretto-11` or `corretto-21.0.5.11.1`, and resolves it to
   a precise version number.
   
   This new `resolve_version_spec()` function is now also called in
   `select_version()`, used by `with_shim_executable()`, meaning that any
   execution of the `asdf` shim (eg, executing `java`) will now resolve
   any version specifications found in the `.tool-versions` file - if
   `.tool-versions` contains `java latest:corretto-21`, this will be
   resolved and the latest version of Java 21 used.
   
   ## Other Information
   
   Previous `asdf` PRs relating to `latest`:
   
   * asdf-vm#575 in November 2019: added the `latest`
     command, eg `asdf latest python 3.6` reports the latest version of Python 3.6.
   * asdf-vm#633 in July 2021: made it possible
     to specify `latest` when using the `local` & `global` commands, eg:
     `asdf local python latest:3.7` - this would save a precise version number
     to `.tools-versions`, which is undesired behaviour for us at the Guardian.
   
   A couple of Guardian systems attempting to standardise on using `.tool-versions`
   as a source of truth:
   
   * guardian/gha-scala-library-release-workflow#36
   * https://github.com/guardian/setup-scala

   

   rtyley committed Oct 22, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for bc95d68
   • Browse repository at this point

   Copy the full SHA

   bc95d68 View commit details

   Browse the repository at this point in the history