Azure-pipelines-tasks: [DotNetCoreInstaller] install latest SDK / runtime -- special versions

[gfoidl]

As version a valid and explicit version must be given, e.g. 2.1.500

I propose to allow special version strings like

• latest
• latest.coherent

to install the latest SDK (from master branch) according to https://dotnetcli.blob.core.windows.net/dotnet/Sdk/master/latest.version

Analogous for the runtime.

[sachinma]

Adding @bishal-pdMSFT and @pulkitaggarwl to consider this request.

[amrock-my]

Perhaps supporting "floating versions" could resolve this in all cases? I created a request (#9243), but I closed it after I found this request was too similar.

[bishal-pdMSFT]

@amrock-my Would it be good if we add support for 2.1.x (or just 2.1) which would mean latest patch for 2.1? 2.x or latest or latest.coherent would mean automatic update across release channels and might not be desired.

[gfoidl]

latest or latest.coherent would mean automatic update across release channels and might not be desired

In my workflow this is desired.

Scenario: a library that uses new features / api that will come with .NET Core 3.0. As the api-design/-surface in .NET Core 3.0 evolves and changes, CI should test against _latest_, to show "out of date" apis as soon as possible.
As the library also supports .NET Core 2.1, etc. fixed version are as well.

[mxmichael]

I'm not sure what latest.coherent means. Does that mean the latest version which is not in preview?

I could foresee a situation where both a keyword and floating versions are accepted. Here are some examples of what is available currently:

• latest would use the latest non-preview version, which is currently 2.2.101.
• 2.2.100 would result in 2.2.100 (exact version specified)
• 2.2.* would result in 2.2.101
• 2.1.* would result in 2.1.502
• 2.* would result in 2.2.101

To include preview versions, just a simple checkbox "include preview versions" would be good? I was just imagining how NuGet supports floating versions and thinking the same could apply to this. Thoughts?

[gfoidl]

I'm not sure what latest.coherent means.

From https://github.com/dotnet/core-sdk#installers-and-binaries:

A 'coherent' build is defined as a build where the Runtime version matches between the CLI and ASP.NET Core.

I would write -- or to be more precise would love to write -- the list from @mxmichael as:

| version | resolves to |
| -- | -- |
| latest | 3.0.100-preview-010006 |
| latest.coherent | 3.0.100-preview-009817 |
| stable | 2.2.101 |
| 2.2.100 | 2.2.100 |
| 2.2.* | 2.2.101 |
| 2.1.* | 2.1.502 |
| 2.* | 2.2.101 |

Otherwise there's no way the get _latest_ .NET Core 3.0 preview versions in a floating manner.

[bishal-pdMSFT]

As per my understanding (based on exchanges with @leecow) usually users like to stick to latest patch version of a particular release channel (A channel is {Major.Minor} release train). They wouldn't want to use a latest version which can one fine day update to new channel.
Hence it looks logical to support only 2.2.x kind of versions in the task and not 2.x or latest.

[gfoidl]

Usually, but not always. See https://github.com/Microsoft/azure-pipelines-tasks/issues/9171#issuecomment-451867102

[mxmichael]

I don't see any harm in offering the additional options beyond 2.2x kinds of versions. I agree with @gfoidl on the table he provided, with perhaps one alternative... instead of just 'stable', perhaps 'latest.stable' for consistency, though that isn't as important as having an option to get the most stable version.

[leecow]

Keep in mind that only the latest patch release of a given major.minor channel is supported. .NET Core's promise is that patch updates are compatible ... full stop. The ability to utilize an older version, side-by-side with a newer version, is a pressure relief valve in the event that a breaking change were to occur.

[bishal-pdMSFT]

@gfoidl

Scenario: a library that uses new features / api that will come with .NET Core 3.0. As the api-design/-surface in .NET Core 3.0 evolves and changes, CI should test against latest, to show "out of date" apis as soon as possible.
As the library also supports .NET Core 2.1, etc. fixed version are as well.

This scenario exactly fits the use case I/Lee mentioned earlier. You would want to test such library against latest patch of 3.0 and 2.1 (and possibly others like 2.2 and 1.1 etc). If a new major version 4.0 gets released, you would want to add additional tests for that rather than 3.0 test automatically updating to 4.0 test.

[mxmichael]

@bishal-pdMSFT: Could you provide a table-based example of inputs and results? As a developer, I can tell you that so far I really like the table suggested by @gfoidl.

[twsouthwick]

I would really like this option as well. I'm porting some WPF apps to .NET Core 3.0 and would like to be able to stay up on the latest SDKs without needing to update my build definitions.

What about using the data at https://github.com/dotnet/core/blob/master/release-notes/releases-index.json and requiring a user to specify the "channel", ie 3.0, 2.2, etc. Not sure what exactly extensions can do at each step, but having an option to specify the channel and having it autopopulate with the correct versions there would be really nice and make the different versions very discoverable.

[gfoidl]

I think with the coming of .NET 5 this is still / more relevant in order to be able to run CI with stable and latest versions of .NET.

[hiyadav]

With UseDotNet V2 task: we have added the functionality to install latest versions by specifying the version spec in the following formats

1. 2.2.x
2. 2.x
3. absolute version: 2.2.108

This also works with DotNetCore 3.0

Hence closing the issue.

[gfoidl]

@hiyadav thx 👍