Make the AssemblyVersion does not change for servicing releases

[daxian-dbw]

PR Context

Make the AssemblyVersion does not change for servicing releases.

Today, the AssemblyVersion of the PowerShell assemblies keeps changing when there is a new servicing release, for example, for PowerShell v7.4.3, the AssemblyVersion is 7.4.3.500, and for PowerShell v7.4.4, it becomes 7.4.4.500. Accordingly, the AssemblyVersion of the reference assembly from the NUGET packages released from each servicing release also keeps changing.

This causes a problem: for a module that depends on PowerShell 7+ NUGET packages, every time it moves to a newer version of NUGET package, it would require a higher version of PowerShell to work. For example, when a module is built against the v7.4.4 of the System.Management.Automation NUGET package, the user would need to have PowerShell v7.4.4 or higher to use the module.

However, in most cases, we need to update the dependency of a module only due to the compliance requirements -- you need to use the most recent version of a NUGET package when it's available, but the module itself doesn't have any security issue and should work just fine on any v7.4.x PowerShell. Requiring the user to always on the latest PowerShell to use a module is unnecessary.

.NET keeps the AssemblyVersion of their framework assemblies unchanged for servicing releases (8.0.0.0 for System.Private.CoreLib.dll or System.Threading.Thread.dll for .NET 8.0.10), and so should we. This PR updates the build a bit to make the AssemblyVerseion of PowerShell assemblies unchanged for servicing releases, so that moving to a newer version of NUGET package to build a module doesn't require a higher version of PowerShell for the module to work.

PR Summary

Explicitly set the FileVersion and AssemblyVersion properties when the release tag is passed in. FileVersion is kept the same as PSCoreFileVersion like before, and AssemblyVersion is set to be PSCoreFileVersion with the Build field setting to 0.

BREAKING CHANGE

This will be a breaking change if we back port the change to PowerShell 7.4.
A module or an application that is built targeting an existing 7.4.x PowerShell NUGET package will not work with a new servicing release after porting this change to 7.4, because the new AssemblyVersion will become 7.4.0.500 but the module/application depends on 7.4.4.500 for example, which is higher.
However, we can make it non-breaking to 7.4 by change the Build field to 500 (for example) when backporting to 7.4.

This is NOT a breaking change for 7.6 preview or for back porting to PowerShell 7.5.

Build Validation

Coordinated package build: https://dev.azure.com/mscodehub/PowerShellCore/_build/results?buildId=550558&view=results
Packages pipeline: https://dev.azure.com/mscodehub/PowerShellCore/_build/results?buildId=550722&view=results

The build branch name is release/v7.4.9, and the AssemblyVersion of PowerShell assemblies is 7.4.0.500, and the reference assembly produced in the nupkg build step also has AssemblyVersion to be 7.4.0.500

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    - [ ] Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively

[iSazonov]

After a number of changes, this code has become somewhat confusing.
If now we have to manually construct version strings maybe simplify the code?
Below there is my commented-out code for version parts. We could move it on top and construct versions strings in more clear ways.

[daxian-dbw]

So far, we only need special case the AssemblyVersion. Other version properties are the same as before.

[microsoft-github-policy-service]

📣 Hey @daxian-dbw, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗 https://aka.ms/PSRepoFeedback

Microsoft Forms

[TravisEz13]

@PowerShell/powershell-maintainers There is no value in waiting for testing is 7.6 preview. Taking for servicing.

Dongbo will create PR for 7.4 to deal with existing releases.

Standard back-port process can be used for 7.5.