Support installing the latest patch or minor version

[JSkimming]

TL;DR

Support a version format of 2.1.x or 2.x and the latest patch or minor version of .NET Core will be installed.

Summary

It's quite a common pattern to be able to omit a minor or patch version and tooling will get the latest version.

For instance Azure Pipeline Use .NET V2 Task provides this mechanism.

This will allow a build matrix like this to be specified:

jobs:
  build:
    runs-on: ubuntu-16.04
    strategy:
      matrix:
        dotnet: [ '2.1', '2.2', '3.0' ]
    name: Dotnet ${{ matrix.dotnet }} sample
    steps:
      - uses: actions/checkout@master
      - name: Setup dotnet
        uses: actions/setup-dotnet@v1
        with:
          dotnet-version: ${{ matrix.dotnet }}
      - run: dotnet build <my project>

The following options would be useful

• 2 or 2.x or 2.* - Installs the latest version of .NET Core 2, currently 2.2.401
• 2.1 or 2.1.x or 2.1.* - Installs the latest version of .NET Core 2.1, currently 2.1.801

[JSkimming]

If you agree this is useful, the following JSON could be used to determine the latest patch versions:

https://github.com/dotnet/core/blob/master/release-notes/releases-index.json

The Azure Pipeline Use .NET V2 Task does exactly this.

I believe hard coding the latest minor version would also be acceptable, as they are changed relatively infrequently.

[rainersigwald]

One major wrinkle here: .NET Core SDK version numbers are not SemVer. Ideally, any wildcard versioning would allow wildcarding within a release band, but not automatically install an SDK incompatible with (for example) Visual Studio 2017 on the relevant Windows image.

[JSkimming]

@rainersigwald, my opinion is that's a risk the consumer take on, as long as it's explicit. Maybe a warning in the output to make it more prominent?

I don't use the 2.x wildcard as I know the SDK may not be compatible between minor versions, but I do use the 2.2.x wildcard a lot, and while I have occasionally found breaking changes, they were considered bugs.

[NickCraver]

A suggestion here: if the other proposals of using global.json (like #14 and #15) are adopted, this could potentially be satisfied by the global.json changes in 3.0, and going to the latest that rollForward allows.

[ZEisinger]

@KathleenDollard is there a timeline or issue for tracking implementation of the design accepted here: https://github.com/dotnet/designs/pull/71/files

[timheuer]

@ZEisinger has the team explored looking at the UseDotnetV2 task from Pipelines? It seems to take a lot of these scenarios into account in acquisition and multi-version install as well.

[ZEisinger]

@timheuer Our thoughts on this action is that we should directly use the dotnet-install scripts. There are are existing issues with the way we install currently that would be solved by adopting those scripts for installation. This seems to be a recurring request that would best be addressed by the dotnet team since this problem will be faced by users using any CI or workflow.

The design linked above would solve this issue once we are using the scripts. Are there plans to implement that design into the scripts?

[timheuer]

@ZEisinger while we are working on improving the versioning story for the SDK, as I mentioned, the Azure Pipelines task handles this scenario well using the release JSON file metadata. Just generally, the feedback I've seen is that adopting the model that the Pipelines task has will solve a few scenarios/feature requests for Actions.

/cc @KathleenDollard

[litetex]

Is there any progress?
It's very difficult to update each workflow that uses this action all 1-2 months by hand, just to get the latest stability / security patches.

Developers will forget to update to the latest version if you don't give them an easy opportunity:

Searching for "dotnet-version: 3.1.100" reveals over 2k results → 2k workflows are affected by 4 vulnerabilities patched in January

You should also consider updating the README.md

[Fronix]

Any progress here, tests are kind of halted right now since 3.1.201 doesn't seem to work at all.