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

[dotnet] latest STS version is stuck on 7.0.410 #1213

Open
sliekens opened this issue Dec 7, 2024 · 9 comments
Open

[dotnet] latest STS version is stuck on 7.0.410 #1213

sliekens opened this issue Dec 7, 2024 · 9 comments

Comments

@sliekens
Copy link
Contributor

sliekens commented Dec 7, 2024

Hi,

It appears that the latest.version (STS) version is no longer being updated, it should report 9.0.101 but it's still on 7.0.410 three weeks after .NET 9 was released. As a result, the dotnet feature still defaults to installing the latest.version (LTS) version (currently 8.0.403) .

Since the latest.version file above is more of a private API used by the dotnet-install script, maybe now is a good time to rewrite this code to use the releases-index.json. More info: README.

@gauravsaini04
Copy link
Contributor

Hi @sliekens
The existing URL's have already been updated to point to the versions 9.0.101 for STS and 8.0.404 for LTS

@sliekens
Copy link
Contributor Author

Ok interesting, was it coincidence? 😁

Regardless, I still think it's a good idea to use the releases index rather than the semi-private URL. I could draft a PR for it.

@gauravsaini04
Copy link
Contributor

Yes sort of a coincidence, had been promptly updated by the dotnet team

The URL's that are present in the feature are maintained by dotnet team only

@sliekens
Copy link
Contributor Author

sliekens commented Dec 26, 2024

@gauravsaini04 this just appeared on my feed: dotnet/core#9671
"Critical: .NET install domains and URLs are changing"

It looks like the devcontainer feature might break after 15 Jan because of this change.

@richlander
Copy link

richlander commented Dec 27, 2024

Yes, the files in this folder will need to change: https://github.com/devcontainers/features/tree/main/src/dotnet

Might it be time for the repo to snap a new copy of the install script? Or is it really necessary for this repo to keep its own copy with this logic?

https://github.com/dotnet/install-scripts/tree/main/src

/cc @baronfel @mmitche

@sliekens
Copy link
Contributor Author

sliekens commented Dec 27, 2024

@richlander the dotnet-install.sh script in this repo is updated weekly via GitHub Actions (update-dotnet-install-script.yml), so that will get resolved as soon as the action runs and the resulting PR is merged.

The thing that won't resolve itself is the use of latest.version (STS) and latest.version (LTS) to detect which channel has the absolute greatest version. I understand using these files for any purpose is not endorsed.

if [ "$runtime" = "dotnet" ]; then
wget -qO- "https://dotnetcli.azureedge.net/dotnet/Runtime/$channel/latest.version"
elif [ "$runtime" = "aspnetcore" ]; then
wget -qO- "https://dotnetcli.azureedge.net/dotnet/aspnetcore/Runtime/$channel/latest.version"
else
wget -qO- "https://dotnetcli.azureedge.net/dotnet/Sdk/$channel/latest.version"
fi

@sliekens
Copy link
Contributor Author

I raised #1230 to stop using azureedge.net

@richlander
Copy link

I asked for the advice on the special files. Naturally, we're a bit short-staffed at the moment. We're going to publish guidance on the various URL types, including the ones you've asked about.

@richlander
Copy link

richlander commented Dec 28, 2024

My team got back to me. Those .version URLs are fine to use. They will be included in the guidance document.

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

No branches or pull requests

3 participants