[release/5.0.1xx-rc2] Use aspnetcore version suffix for template install directory #8625
Conversation
This change is required for RTM stable builds. When stable versions are generated the CalculateTemplateVersions task will fail. For .NET 3.x, installer is partially on arcade. It uses its own versioning model, but the arcade generated versions are actually set (specifically VersionSuffix). So even when stable builds are generated, VersionSuffix is available. It is unused when the aspnetcore template versions are stable. For .NET 5, installer is now fully on arcade versioning, which means VersionSuffix is not set when stable versions are generated. Instead of using installer's version suffix if aspnetcore's template versions are unstable, use the version suffix of the aspnetcore template versions. This subtley affects the installer directory of the templates: - If the aspnetcore version is: `5.0.0-rc.1.1234.5` - And the installer version is: `5.0.100-rc.1.9999.9` - Template install dir before: .dotnet\templates\rc.1.1234.5 - Template install dir after: .dotnet\templates\5.0.2-rc.1.9999.9 Of note: The overall template layout doesn't make a ton of sense. The aspnetcore template version is used for the install directory, but many different templates are put in this directory, including some that have completely different versions.
|
@marcpopMSFT I'm not sure whether to call this infra or product. It shows up in the product, but only as a minor tweak in a directory name in builds that contain non-stable aspnetcore versions. |
|
@mmitche do we know of any scenario that relies on those directories? If it's just cosmetic and shouldn't affect functionality, I'd consider it infrastructure. Note also that the SDK is still in free checkin mode even for product changes but goes into tell mode starting Monday. |
Not that I know of. Note that this should also not affect the folder structure for RTM/servicing scenarios |
|
@wli3 @marcpopMSFT Any objections? |
|
Seems like a reasonable change. @wli3, mind taking a quick look? |
|
let me read it carefully. If something is wrong, it will break "dotnet new" |
|
Sorry that i did not see this PR sooner |
Agree. But we never get time to solve it the right way. |
This is not right. This is my template current folder
|
|
Yeah I was just looking at my description, definitely wrong. Updating it right now. |
|
Updated. |
I don't think so. We don't use version.props at least. And we still use commit height in some area |
|
It is lost knowledge for why we used versionsuffix in the beginning. However that worked for one release. And I guess using versionsuffix will generate a different folder name for each installer. Using aspnet suffix will not promise that. As you see, we could have different other templates using the same aspnet suffix |
|
Chatted with @wli3 and decided this change is safe. Moreover, it doesn't change behavior in any RTM/servicing builds. |
This change is required for RTM stable builds. When stable versions are generated the CalculateTemplateVersions task will fail.
For .NET 3.x, installer is partially on arcade. It uses its own versioning model, but the arcade generated versions are actually set (specifically VersionSuffix). So even when stable builds are generated, VersionSuffix is available. It is unused when the aspnetcore template versions are stable.
For .NET 5, installer is now fully on arcade versioning, which means VersionSuffix is not set when stable versions are generated.
Instead of using installer's version suffix if aspnetcore's template versions are unstable, use the version suffix of the aspnetcore template versions. This subtley affects the installer directory of the templates:
5.0.0-rc.1.1234.55.0.100-rc.1.9999.9Then:
Of note: The overall template layout doesn't make a ton of sense. The aspnetcore template version is used for the install directory, but many different templates are put in this directory, including some that have completely different versions.