-
Notifications
You must be signed in to change notification settings - Fork 585
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
Comments
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 |
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. |
@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 |
I'm not sure they are, as far as I understand it you need to concat the base link and the filename:
Well obviously intellisense would be very nice, but I can see how that might become a bit difficult. Realistically validation at runtime against the json is probably the easiest (or even just running the installer and not using the json at all) |
Ah, of course!
If we do that, is it the same as just deprecating the |
Another option would be promoting the use of a |
I'd say generally yes, but it depends a bit on how "usable" the new way is.
Well the option is there, personally I like to use "latest" locally and lock the version on the CI (ie in build.fsx without |
@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:
The I have a few questions, whose answers will hopefully lead to a solution:
If we are okay with the following 2 statements, then I believe that we can, to a certain degree, automate the creation of
If the above is acceptable, then my plan is as follows: Write a simple type provider to create the entries in
Please let me know what you think, and I will proceed accordingly. |
@zakaluka Sorry for the late reply.
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).
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.
Yes that's fine by me.
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.
I think that would be awesome. Let me know if you need any help. |
I am closing this old discussion. I'm open to PRs, but I haven't heard a lot of complaints regarding this lately. |
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:
The text was updated successfully, but these errors were encountered: