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

Long-term strategy to handle .NET SDK versions #2090

Closed
zakaluka opened this issue Sep 15, 2018 · 10 comments
Closed

Long-term strategy to handle .NET SDK versions #2090

zakaluka opened this issue Sep 15, 2018 · 10 comments

Comments

@zakaluka
Copy link

zakaluka commented Sep 15, 2018

Description

Per #2089, @matthid mentioned that an easier / better long-term strategy is needed to handle SDK versions, as there are a lot of them.

This issue is to discuss options, suggestions, and solutions. Initial ideas from the other ticket:

  1. Try to get a list of links from https://dotnetcli.azureedge.net/dotnet/ and use that to generate available SDK versions.
  2. Parse .NET SDK pages, such as https://www.microsoft.com/net/download/dotnet-core/2.2, and use the information to generate available SDK versions.
  3. Use https://github.com/dotnet/core/blob/master/release-notes/releases.json to generate available SDK versions.
  4. "Hard-coding" major and minor versions, and allowing users to specify the patch number.
@matthid
Copy link
Member

matthid commented Sep 15, 2018

For context: The Azure DevOps "DotNet Installer"-Task is using option 3 to check if a version entered by the user is valid (and to get latest): https://github.com/Microsoft/vsts-tasks/blob/3d033783bdc2dfdeebec23ae6ca067714f6cad0d/Tasks/DotNetCoreInstallerV0/releasesfetcher.ts#L137

@zakaluka
Copy link
Author

One thing I found is that the links in option 3 are broken - not sure if that's a sign of anything significant. The versions available in option 3 are also different than what I see (in some cases) than option 2.

@zakaluka
Copy link
Author

@matthid what do you think is the goal - intellisense when it comes to picking a version or validating that a potentially "free text" (wholly or partial) version is correct?

Sorry for the naive question, but would intellisense require some form of code generation, almost like a pre-compilation step, to generate the Versions module before the compiler gets to it? Or are there other tricks (quotations, though I have never used them so not sure they would help here) that can be used to create the equivalent of let declarations dynamically?

@matthid
Copy link
Member

matthid commented Sep 15, 2018

One thing I found is that the links in option 3 are broken

I'm not sure they are, as far as I understand it you need to concat the base link and the filename:

https://dotnetcli.blob.core.windows.net/dotnet/Runtime/2.2.0-preview2-26905-02/ + dotnet-runtime-2.2.0-preview2-26905-02-linux-x64.tar.gz for example

intellisense when it comes to picking a version or validating that a potentially "free text" (wholly or partial) version is correct?

Well obviously intellisense would be very nice, but I can see how that might become a bit difficult.
I think the only real way to enable that would be type-provider, or our own type provider.

Realistically validation at runtime against the json is probably the easiest (or even just running the installer and not using the json at all)

@zakaluka
Copy link
Author

I'm not sure they are, as far as I understand it you need to concat the base link and the filename:

https://dotnetcli.blob.core.windows.net/dotnet/Runtime/2.2.0-preview2-26905-02/ + dotnet-runtime-2.2.0-preview2-26905-02-linux-x64.tar.gz for example

Ah, of course!

Well obviously intellisense would be very nice, but I can see how that might become a bit difficult.
I think the only real way to enable that would be type-provider, or our own type provider.

Realistically validation at runtime against the json is probably the easiest (or even just running the installer and not using the json at all)

If we do that, is it the same as just deprecating the DotNet.Versions and relying on global.json?

@sliepie
Copy link
Contributor

sliepie commented Sep 15, 2018

Another option would be promoting the use of a global.json file. The benefits of this are always same version of sdk as other dot.net tooling uses, and you don't have to update your build script for adjusting the sdk.

@matthid
Copy link
Member

matthid commented Sep 16, 2018

If we do that, is it the same as just deprecating the DotNet.Versions and relying on global.json?

I'd say generally yes, but it depends a bit on how "usable" the new way is.

Another option would be promoting the use of a global.json file. The benefits of this are always same version of sdk as other dot.net tooling uses, and you don't have to update your build script for adjusting the sdk.

Well the option is there, personally I like to use "latest" locally and lock the version on the CI (ie in build.fsx without global.json). I have not yet heard an argument against that...

@matthid matthid assigned matthid and unassigned matthid Sep 22, 2018
@zakaluka
Copy link
Author

zakaluka commented Sep 24, 2018

@matthid So, looking into this further, it seems that we use the following URL to download the install script that will, in turn, download and install the given SDK version:

sprintf "https://raw.githubusercontent.com/dotnet/cli/%s/scripts/obtain/%s" branch installerName

The branch corresponds to the GitHub branch from which we want to download the installation script.

I have a few questions, whose answers will hopefully lead to a solution:

  1. Why do we use the installation scripts from particular branches instead of the latest installer scripts (from the website - https://dot.net/v1/dotnet-install.sh and https://dot.net/v1/dotnet-install.ps1 - or from master)?
    • From testing on the entries in releases.json, the only times the latest script doesn't work is when the blob-sdk URL does not start with https://dotnetcli.blob.core.windows.net/dotnet/Sdk/. This seems to be limited to 5 entries in releases.json, all for 1.0.0-preview2-*.
    • I am making an assumption that the installer will finish successfully for the remaining 42 entries in releases.json, but I haven't done extensive testing for each of those entries.
  2. If there is a reason behind using older installation scripts, how have you been determining which branch's installation script matches the SDK version you want to install?
    • Are you using the runtime version to match find the branch, then setting the Version based on one of the other sites that states which SDK version correlates to which runtime version?

If we are okay with the following 2 statements, then I believe that we can, to a certain degree, automate the creation of Versions based on releases.json.

  1. Drop support for SDK versions 1.0.0-preview2-* (about 5 of the 47 entries in releases.json). FAKE doesn't seem to support these today anyway.
  2. Use the latest installation script (either master or the one at the link above) instead of scripts from a specific branch.

If the above is acceptable, then my plan is as follows:

Write a simple type provider to create the entries in Fake.DotNet.DotNet.Versions. This will probably change from a module (as it is currently) to a type with properties. However, since this will be my first type provider, I can't say for sure.

Please let me know what you think, and I will proceed accordingly.

@matthid
Copy link
Member

matthid commented Oct 7, 2018

@zakaluka Sorry for the late reply.

Why do we use the installation scripts from particular branches instead of the latest installer scripts (from the website - https://dot.net/v1/dotnet-install.sh and https://dot.net/v1/dotnet-install.ps1 - or from master)?

This is because of possible "breaking changes" in the script itself. I have seen that strategy somewhere and copied it (don't ask me where).

If there is a reason behind using older installation scripts, how have you been determining which branch's installation script matches the SDK version you want to install?

I guess this is a manual process for now as we basically "lock" the branch in addition to an version and we can change that later if needed (bug-reports come in for example). We don't have any strategy there at the moment to be honest.

Drop support for SDK versions 1.0.0-preview2-* (about 5 of the 47 entries in releases.json). FAKE doesn't seem to support these today anyway.

Yes that's fine by me.

Use the latest installation script (either master or the one at the link above) instead of scripts from a specific branch.

I'm not sure about that, that locks us into a situation where a breaking change in the script breaks everyone. I think we need a more robust strategy here.

Write a simple type provider to create the entries in Fake.DotNet.DotNet.Versions.

I think that would be awesome. Let me know if you need any help.

@matthid
Copy link
Member

matthid commented Apr 14, 2019

I am closing this old discussion. I'm open to PRs, but I haven't heard a lot of complaints regarding this lately.

@matthid matthid closed this as completed Apr 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants