Closed jberezanski closed 3 years ago
But why?! The property is actually named version-runtime
so shouldn't we expect it to be the 'version runtime'!
I thought so too... until 2.0.8 happened. In that release, version-runtime
= 2.0.8, but the Runtime (as in: dotnet-runtime-X.Y.Z-win-x64.exe) is still 2.0.7 (unchanged from the previous release). This leads to the conclusion that version-runtime
is something like the version number of the overall release of the runtime components subset of .NET Core (a set consisting of: the actual Runtime, the ASP.NET Core package store and the Windows Server hosting bundle), but individual components in that set do not necessarily need to have the same version.
If we do nothing and Microsoft decides to make another release like this (with non uniform component version numbers), our AU machinery will publish some packages with invalid version (like it happened a few days ago).
Have you seen the update https://github.com/dotnet/core/issues/1605#issuecomment-393241305?
Yes, but that comment only tells their plans for 2.0.9, it does not promise "we'll never do this again". This issue is about taking measures to protect our packages from future issues.
It seems that the versioning format has matured and stabilized, so this is no longer a valid concern.
...or is it...?
https://github.com/dotnet/core/issues/2139#issuecomment-446631508
it is possible to have an SDK release which includes previously released runtimes
thankfully https://github.com/dotnet/core/issues/2134#issuecomment-447069916
aspnet and net core runtime version version alignment from 2.0 onward will be stable.
Like in #29. The .NET Core 2.0.8 release contained the 2.0.7 runtime, unchanged.
In order to handle such scenarios correctly, AU scripts should parse component versions out of the file names, instead of using the "version-runtime" json property.