richlander commented 2 years ago

Evergreen dotnet links

We would like to offer evergreen links to make downloading .NET easier. Today, .NET links are not predictable (and have guids in them). We already have some links like this but they target preview and daily releases, not stable ones.

FYI: This is a proposal. These links don't yet exist.

Characteristics

Let's define the desired characteristics of evergreen links:

Short
Enable targeting all the common downloads
Serviced (roll-forward to later patches as they become available)

One can imagine a broader set of links. We can consider providing a broader set at a later time, per feedback.

Here's an example of the links we have today, You can see that they don't satisfy these characteristics:

https://download.visualstudio.microsoft.com/download/pr/c246f2b8-da39-4b12-b87d-bf89b6b51298/2d43d4ded4b6a0c4d1a0b52f0b9a3b30/dotnet-sdk-6.0.302-win-x64.exe

Daily builds link scheme

Let's look at the link scheme that is being used at dotnet/installer and dotnet/runtime:

That's a smattering of links to get the idea. We don't need a quality level, so we can remove daily. We also don't want to use aka.ms. Other than that, these links look good.

Evergreen link scheme

Here's the basic scheme we want:

https://get.dot.net/[version]/dotnet-[component]-[rid].[ext]

Note: the get.dot.net subdomain already exists. We need to determine if we can re-use it for this purpose.

We should support the following versioning schemes:

Major version, like 7.0 for runtime and SDK components (latest 7.x build)
Hundreds band SDK, like 7.0.1xx (pinned to a hundreds band but rolls forward on patch)

We should support the following components:

sdk
runtime
aspnetcore-runtime
windowsdesktop-runtime

We should support the following RIDs for the first three components (alpha order):

linux-arm64
linux-musl-arm64
linux-musl-x64
linux-x64
osx-arm64
osx-x64
win-arm64
win-x64
win-x86

Note: osx is seeming arcane at this point, however macos isn't technically a RID. This should be specifically considered outside the merits of the overall proposal.

We should support the following RIDs specifically for windowsdesktop-runtime (alpha order):

win-arm64
win-x64
win-x86

The file extension is purely a function of the distribution, like .zip or .exe.

Could we break all these components into slashes instead of this long filename? Yes, but it would have two problems. The first is that it wouldn't be obvious what to pass curl -o. The second is that the final URL would just be a bunch of duplicate information and some people would learn that and target it. That would be silly.

Checksums

We should consider offering checksums for all these packages. The dotnet/installer page offers that (I believe) exclusively with a .sha extension added to all of the URLs. That's compelling and seemingly straightforward. We should demonstrate how to download and validate these packages securely.

Timing

The whole point of evergreen links is that they serve newer content each month. When they switch to the newer content is a policy. To start, we should switch to serving newer content when the website does. If there is a reason to delay it, we can consider doing that.

Content

These links serve up binaries. They do end up with a web page that auto-downloads content.

This command needs to work:

curl -Lo dotnet-sdk-linux-musl-x64.tar.gz https://get.dot.net/sdk/7.0/dotnet-sdk-linux-musl-x64.tar.gz

Same with this command:

wget https://get.dot.net/sdk/7.0/dotnet-sdk-linux-musl-x64.tar.gz

mthalman commented 2 years ago

I think long-term it would be useful to have the versioning scheme support patch versions as well.

Consider the scenario where a script has been configured to use this new evergreen URL scheme and the maintainer of that script has run into an issue that they think may be related to the .NET installation. To verify, they want to revert back to the previous patch version. They know what that version is, but now they have to dig through all the release content to find what those URLs are to be able to target that patch version. Instead, if the versioning scheme proposed here had support for patch versions, it would simply be a matter of changing 7.0 to 7.0.x in their existing URL.

richlander commented 2 years ago

Agreed. It's trivial to do. We just need to decide what scope to take on initially. Certainly, I can see your scenario.

Let's say we did that. Would you move our Dockerfiles to that? And same for the checksums? That would certainly simplify the Dockerfiles? We'd only have to change one value per release, right?

I'm mostly asking if we could move L9 to static content? https://github.com/dotnet/dotnet-docker/blob/1008cddf981deb3442985e063e588df2a0861b87/src/runtime/6.0/jammy/amd64/Dockerfile#L8-L9

richlander commented 4 months ago

Was just updating tailscale. They have a quite nice experience.

rich@kamloops:~$ sudo tailscale update
Password: 
This will update Tailscale from 1.56.1 to 1.62.0. Continue? [y/n] y
Downloading "https://pkgs.tailscale.com/stable/tailscale-x86_64-1.62.0-700062000-dsm7.spk"
Download size: 27209728
Downloaded 512/27209728 (0.0%)
Downloaded 27209728/27209728 (100.0%)
Downloading "https://pkgs.tailscale.com/stable/tailscale-x86_64-1.62.0-700062000-dsm7.spk.sig"
Signature OK

These particular links include version numbers (which we do not want) but they do have matching file names (minus extension) for binary and checksum file.

FYI: We produce SHA512 checksums. I've since noticed that some systems only support SHA256, like Dockerfile.

dotnet / core