Update VersionFeature80 and VersionFeature90 calculations to Jan release#52495
Update VersionFeature80 and VersionFeature90 calculations to Jan release#52495marcpopMSFT merged 2 commits intorelease/10.0.2xxfrom
Conversation
|
I believe we determined that we didn't need to update the runtime as codeflow will do that. We do need to update the implicit version before release though. |
|
This is needed for GA but should not be in the preview so holding for now. |
There was a problem hiding this comment.
Pull request overview
Updates how the repo computes the .NET 8 and .NET 9 servicing “feature” versions (used for bundled runtime/targeting pack version selection) to align with the January release numbers.
Changes:
- Switch
VersionFeature80andVersionFeature90from hard-coded values to MSBuild-calculated values based on$(VersionFeature). - Update the implied net8/net9 patch baselines to 25 and 14 respectively (January release alignment).
| <!-- This version should be N-1 (ie the currently released version) in the preview branch but N-2 in main so that workloads stay behind the unreleased version --> | ||
| <VersionFeature80>23</VersionFeature80> | ||
| <VersionFeature90>12</VersionFeature90> | ||
| <VersionFeature80>$([MSBuild]::Add($(VersionFeature), 25))</VersionFeature80> | ||
| <VersionFeature90>$([MSBuild]::Add($(VersionFeature), 14))</VersionFeature90> |
There was a problem hiding this comment.
Deriving VersionFeature80/90 from $(VersionFeature) means a PR that only bumps will now also implicitly change the net8/net9 runtime/targeting pack versions at build time. This can break automation/policy that treats “only changed in eng/Versions.props” as a low-impact change (e.g., .github/workflows/remove-lockdown-label.yml checks the diff for only). Consider keeping VersionFeature80/90 explicit, or updating the automation/policy to account for these derived properties so branch-lockdown behavior stays correct.
No description provided.