dotnet / installer

.NET SDK Installer
https://github.com/dotnet/sdk
1.27k stars 446 forks source link

Distribute preview releases with packages.microsoft.com #7683

Closed richlander closed 6 months ago

richlander commented 4 years ago

Distribute preview releases with packages.microsoft.com

The primary model for software distribution on Linux is via a package manager. We distribute .NET via packages.microsoft.com (Microsoft's Linux package feed; supports multiple distros), but only for stable releases. This is unfortunate, since most people want to rely on the same acquisition patterns for all .NET releases, stable, preview or otherwise. When someone reads one of our exciting preview announcement blog posts, they naturally want to respond to our call to action to try out and test new features. We expect that many Linux users pass on these releases because they cannot coveniently install and use them. We've seen .NET users on Linux being frustrated by this, and it also means we're missing out on valuable preview usage on Linux that would result in earlier product feedback.

Relevant feedback:

Note: This feedback is old. It would be good to see some more recent feedback. Perhaps, .NET Linux users can contribute that.

A hypothesis is that we have this problem due to a lack of preview testing on Linux, not due to anything unique to Linux or package manager behavior.

We could improve this situation by doing the following:

Another hypothesis is that a package manager cannot easily separate preview from stable versions for shared components (discussed later).

We could improve this situation by offering multiple feeds/channels:

Details

Preview releases are available for Linux but as .tar.gz "tarball" "binaries". People can download those, so what's the problem? There are two problems:

This problem isn't new with .NET 5. We've known about it for a long time. The primary issue is that installing a preview can negatively affect a stable release. "What? I thought .NET Core was a side-by-side install". .NET does have side-by-side installs, but there are two files that are shared across .NET versions:

Note: Linux-style names are used above.

See (my WSL2 Ubuntu 20.04 instance):

rich@mazama:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04 LTS
Release:        20.04
Codename:       focal
rich@mazama:~$ which dotnet
/usr/bin/dotnet
rich@mazama:~$ ls -l /usr/bin/dotnet
lrwxrwxrwx 1 root root 24 Apr 30 14:18 /usr/bin/dotnet -> /usr/share/dotnet/dotnet
rich@mazama:~$ ls /usr/share/dotnet/
LICENSE.txt  ThirdPartyNotices.txt  dotnet  host  packs  sdk  shared  templates
rich@mazama:~$ ls /usr/share/dotnet/host/fxr/5.0.0-preview.4.20227.9/
libhostfxr.so

Bugs in these preview files can negatively affect stable versions. There are other aspects of a preview install that can cause problems for an existing stable one. For example, the preview version of NuGet can have a bug that corrupts the NuGet cache in a way that the older version of NuGet is no longer able to function.

Thinking about this from a Windows and Visual Studio perspective, we see this exact situation on a daily basis. Engineers on the .NET team are encouraged to install Visual Studio on their Windows machines from multiple Visual Studio channels. For example, on my machine, I have Visual Studio Community (stable) and Visual Studio Professional (preview) installed. Most of the engineers on the team also have Visual Studio installed from an internal-only channel. Each of the Visual Studio installers, from the various channels, install a different version of the .NET SDK. The .NET version installed via the preview and internal channels is almost always a preview build. This situation isn't limited to .NET team engineers. We also require people in the .NET community to install preview builds, to use .NET previews in Visual Studio. Anyone who installs both stable and preview (or internal) Visual Studio versions is subject to a similar situation as the one that we are discussing with Linux.

This model works on Windows because we get a ton of continuous ad-hoc testing on Windows, so any breakages in hostfxr, for example, get identified quickly. hostfxr is the component most likely to introduce a break like this - the latest version of that component is used, even if it is preview. The amount of ad-hoc side-by-side testing for Linux is low, and for a distro like Alpine is close to zero. The fix for that may be to add test cases for this to our "CTI validation" test phase (FYI: CTI is Microsoft contractor testing).

marcpopMSFT commented 6 months ago

Old issue triage: @richlander is this still relevant?

richlander commented 6 months ago

Can close.

perlun commented 2 months ago

@richlander - should we reconsider and reopen this? There doesn't seem to be any "canonical" issue for getting this resolved AFAICT. https://github.com/dotnet/runtime/issues/3324 refers to this issue, and we then have https://github.com/dotnet/core/issues/5445 and https://github.com/dotnet/core/issues/5446.

Is perhaps https://github.com/dotnet/core/issues/5445 to be seen as the "canonical" issue for this after all? If so, feel free to keep this closed. :+1: I guess the important part is the "getting the resolved" part, not focusing so much on which issue is tracking it. :sweat_smile:

richlander commented 2 months ago

We talked about this again recently and came to the same conclusion. We are not going to invest in delivering preview releases via PMC. It has higher expense than we want and isn't all that high on our priority list.

perlun commented 2 months ago

Got it. :+1: I found out that there are indeed packages available though, just a bit more hidden away. :see_no_evil: More details: https://github.com/dotnet/core/issues/5445#issuecomment-2315070317