PR Context

Make theAssemblyVersion does not change for servicing releases.

Today, theAssemblyVersion of the PowerShell assemblies keeps changing when there is a new servicing release, for example, for PowerShell v7.4.3, theAssemblyVersion is7.4.3.500, and for PowerShell v7.4.4, it becomes7.4.4.500. Accordingly, theAssemblyVersion 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 theSystem.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 theAssemblyVersion of their framework assemblies unchanged for servicing releases (8.0.0.0 forSystem.Private.CoreLib.dll orSystem.Threading.Thread.dll for .NET 8.0.10), and so should we. This PR updates the build a bit to make theAssemblyVerseion 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 theFileVersion andAssemblyVersion properties when the release tag is passed in.FileVersion is kept the same asPSCoreFileVersion like before, andAssemblyVersion is set to bePSCoreFileVersion with theBuild 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 newAssemblyVersion will become7.4.0.500 but the module/application depends on7.4.4.500 for example, which is higher.
However, we can make it non-breaking to 7.4 by change theBuild field to500 (for example) when backporting to 7.4.

This isNOT 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 isrelease/v7.4.9, and theAssemblyVersion of PowerShell assemblies is7.4.0.500, and the reference assembly produced in the nupkg build step also hasAssemblyVersion to be7.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 notWork in Progress.
  • If the PR is work in progress, please add the prefixWIP: or[ WIP ] to the beginning of the title (theWIP bot will keep its status check atPending 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