You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Core-SDK uses the build asset location to download bits, and having each stable build publish to the same location requires an overwrite, and dependency traceability is lost. There are also race conditions.
Core-Setup should always use an unstable version so that each build is available and no overwrites occur.
Note that Core-Setup needs to publish some package that has the unstable version, so that Core-SDK can use the version from that asset to find the virtual dir on dotnetcli. For example, Core-SDK needs to know the unstable and stable version to find this file:
+cc @MichaelSimons, a future plan to use two types of version in the runtime download path to avoid overwrites. I think this will need changes in Docker download and version uptake. Example:
Closing: I think this will be out of our control when moving to Arcade's blob publishing (https://github.com/dotnet/core-setup/issues/8285). It would be good for this to be supported by Arcade in some way. (Or superseded by a new feed feature?)
@dagood Interestingly, it did do this for AspNetCore with arcade's publishing, something to keep in mind if your move in #3675 doesn't yield the expected results.
Note that this issue is talking about the build asset location, e.g.:
https://dotnetcli.blob.core.windows.net/dotnet/Runtime/3.1.0/dotnet-runtime-3.1.0-win-x64.exe
not the channels ("latest" links), which should remain the same:
https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/3.1/dotnet-runtime-latest-win-x64.exe
Core-SDK uses the build asset location to download bits, and having each stable build publish to the same location requires an overwrite, and dependency traceability is lost. There are also race conditions.
Core-Setup should always use an unstable version so that each build is available and no overwrites occur.
Note that Core-Setup needs to publish some package that has the unstable version, so that Core-SDK can use the version from that asset to find the virtual dir on
dotnetcli
. For example, Core-SDK needs to know the unstable and stable version to find this file:https://dotnetcli.blob.core.windows.net/dotnet/Runtime/3.1.0-rc1.12345.1/dotnet-runtime-3.1.0-win-x64.exe
/cc @mmitche
The text was updated successfully, but these errors were encountered: