Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for installing the latest stable version of a tool #575

Merged
merged 9 commits into from
Nov 22, 2019

Conversation

klane
Copy link
Contributor

@klane klane commented Sep 29, 2019

Summary

This PR integrates the logic from xxenv-latest to install the latest stable version of a tool. It adds a latest command to show the latest version:

  • asdf latest python prints 3.7.4
  • asdf latest python 3.6 prints 3.6.9

This gets used by asdf install to install the latest version:

  • asdf install python latest installs Python 3.7.4
  • asdf install python latest:3.6 installs Python 3.6.9

It also adds the ability to filter versions returned by asdf list-all by accepting an additional version substring:

  • asdf list-all python 3.7 only lists Python 3.7 versions

Fixes: #216

Other Information

I need to add unit tests. Any suggestions are welcomed.

@klane
Copy link
Contributor Author

klane commented Sep 30, 2019

I added unit tests and updated the documentation. Please let me know if you want any changes.

@GreenGremlin
Copy link

Let's get this merged!

@vic
Copy link
Contributor

vic commented Nov 22, 2019

Nice work @klane. Could you please add an entry on the changelog about your changes?

@klane
Copy link
Contributor Author

klane commented Nov 22, 2019

Thanks @vic. I rebased on the master branch and updated the CHANGELOG.

@vic vic merged commit fd3469a into asdf-vm:master Nov 22, 2019
@vic
Copy link
Contributor

vic commented Nov 22, 2019

@klane Thanks a lot ! 🎉

@klane klane deleted the install-latest branch November 23, 2019 20:20
rtyley added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
Previous PRs relating to `latest`:

* asdf-vm#575
* 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.
rtyley added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
Previous 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.
rtyley added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
### Implementation

A new `resolve_version_spec()` function is 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
definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

This new `resolve_version_spec()` function is now called in
`select_version()`, used by the `with_shim_executable()` function,
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 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.
rtyley added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
### 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
definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

This new `resolve_version_spec()` function is now called in
`select_version()`, used by the `with_shim_executable()` function,
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 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.
rtyley added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
### 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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

This new `resolve_version_spec()` function is now called in
`select_version()`, used by the `with_shim_executable()` function,
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 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.
rtyley added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
This change enables `asdf`'s existing latest-version-resolution
functionality within the `.tool-versions` file itself, ie 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
```

Currently, using `latew` `asdf local python latest:3.7`

### 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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

This new `resolve_version_spec()` function is now called in
`select_version()`, used by the `with_shim_executable()` function,
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 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.
rtyley added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
This change enables `asdf`'s existing latest-version-resolution
functionality within the `.tool-versions` file itself, ie 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

In 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 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 observations 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 projects.

### 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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

This new `resolve_version_spec()` function is now called in
`select_version()`, used by the `with_shim_executable()` function,
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 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.
rtyley added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
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 observations 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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

This new `resolve_version_spec()` function is now called in
`select_version()`, used by the `with_shim_executable()` function,
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 added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

This new `resolve_version_spec()` function is now called in
`select_version()`, used by the `with_shim_executable()` function,
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 added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 17, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 18, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 18, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 18, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 18, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 18, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 18, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 18, 2024
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 definite installed version number (if the resolved version is not
installed, the appropriate error message is shown).

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 added a commit to guardian/asdf that referenced this pull request Oct 18, 2024
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 added a commit to guardian/asdf that referenced this pull request Oct 22, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add command to install latest stable version of a tool
3 participants