Stop requiring VersionPrefix updates in servicing - insert prerelease versions to VS

[ViktorHofer]

In reaction to this Teams discussion: https://teams.microsoft.com/l/message/19:a15e1e2b222b47388462f825932efb82@thread.tacv2/1783066849424?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47&groupId=f136bf3b-1656-40aa-b7b3-50ea73de9268&parentMessageId=1783066849424&teamName=MSBuild%20Team&channelName=MSBuild%20Team&createdTime=1783066849424

This follows the Roslyn approach and inserts prerelease package versions (same as for main) to VS instead of stabilized versions that need to bumped with every single incoming PR.

We leverage the NuGetRepack tool to create Release and PreRelease variants of our packages for the manual push to nuget.org.

This reduces the steady cost (no VersionPrefix increments needed anymore every time a dependency update is coming in, no PreReleaseVersionLabel and no DotNetFinalVerisonKind updates needed anymore) and simplifies the release checklist activities. Customers won't see weird package versions like 17.12.50 anymore where the patch number was bumped every time a PR was incoming and not every time we were shipping a servicing release.

We still need to increment the VersionPrefix but now as part of the monthly release version update following the same process as other .NET repositories in our stack. I will follow-up on that in a separate PR.

[github-actions]

🔍 Skill Validator Results

✅ All checks passed

Scope	Checked
Skills	1
Agents	0
Total	1
Severity	Count
---	---:
❌ Errors	0
⚠️ Warnings	0
ℹ️ Advisories	0

Summary

Level	Finding
ℹ️	Found 1 skill(s)
ℹ️	[merge-dependency-updates] 📊 merge-dependency-updates: 2,052 BPE tokens [chars/4: 1,913] (detailed ✓), 16 sections, 7 code blocks
ℹ️	✅ All checks passed (1 skill(s))

Full validator output

```text Found 1 skill(s) [merge-dependency-updates] 📊 merge-dependency-updates: 2,052 BPE tokens [chars/4: 1,913] (detailed ✓), 16 sections, 7 code blocks ✅ All checks passed (1 skill(s)) ```

[Copilot]

Pull request overview

This PR updates MSBuild’s servicing/release workflow to stop requiring frequent VersionPrefix bumps by keeping VS insertions on prerelease package versions (aligned with the stated Roslyn-style approach), removing the stabilization script/CI enforcement, and updating release documentation accordingly.

Changes:

• Removes scripts/Stabilize-Release.ps1 and the PR-time CI gate that enforced VersionPrefix bumping on vs* branches.
• Adjusts versioning/tooling configuration in eng/Versions.props (notably the prerelease label and enabling UsingToolNuGetRepack).
• Updates release docs/checklist and the dependency-update skill instructions to match the new servicing expectations.

Show a summary per file

File	Description
scripts/Stabilize-Release.ps1	Removes the prior “final branding” automation script.
eng/Versions.props	Switches prerelease labeling approach and enables NuGetRepack tooling.
documentation/release.md	Removes mention of the stabilization script and updates release flow narrative.
documentation/release-checklist.md	Removes final-branding steps and updates publishing/insertion checklist language.
.vsts-dotnet-ci.yml	Removes the CI job that enforced VersionPrefix bumps on release branches.
.github/skills/merge-dependency-updates/SKILL.md	Updates dependency-update guidance to only bump VersionPrefix on older vs* branches.

Copilot's findings

• Files reviewed: 6/6 changed files
• Comments generated: 3

[github-actions]

Caution

agentic threat detected
Threat detection flagged this output in warn mode. Manual review is REQUIRED before any follow-up automation.

Details

The threat detection results could not be parsed.

Review the workflow run logs for details.

Expert Review — PR #14277

Stop requiring VersionPrefix updates in servicing — insert prerelease versions to VS

Overall this is a well-scoped, low-risk infrastructure improvement. 21/24 dimensions are LGTM. Three moderate/nit issues below.

---

🟡 [MODERATE] Dimension 18 — Documentation Accuracy: stale "Final-branded" language

Two documentation locations still use language that was accurate under the old flow but is now misleading:

documentation/release.md timeline section (unchanged context line):

* Before INSIDERS_SNAP_DATE — Phase 4
  - OptProf bootstrap
  - Final-branded bits land in VS main     ← still says "Final-branded"

documentation/release-checklist.md Inputs table (unchanged):

| `{{INSIDERS_SNAP_DATE}}` | Date VS snaps `main` → `rel/insiders`. Final-branded MSBuild must be in VS `main` **before** this date.

After this PR, what lands in VS main are prerelease-versioned bits (18.10.0-1.XXXXX.YY), not final-branded ones. A release engineer following these docs might incorrectly interpret a prerelease insertion as broken.

Recommendation: Update both occurrences — e.g., change "Final-branded bits land in VS main" → "Prerelease-versioned bits land in VS main" and "Final-branded MSBuild must be in VS main" → "MSBuild prerelease bits must be in VS main".

---

🟡 [MODERATE] Dimension 20 — Scope & PR Discipline: follow-up not tracked

The PR description says:

"We still need to increment the VersionPrefix but now as part of the monthly release version update following the same process as other .NET repositories in our stack. I will follow-up on that in a separate PR."

No tracking issue is linked for this follow-up. If the VersionPrefix increment process change is missed before the next release cycle, the release team may lack procedural clarity.

Recommendation: Open a GH issue for "Monthly VersionPrefix increment process update" and link it from the PR description before merging.

---

🔵 [NIT] Dimension 10 — Design: Teams discussion not accessible externally

The sole design rationale links to a Microsoft Teams message (teams.microsoft.com/l/message/...) that is inaccessible to external contributors and future team members. The deleted comment in eng/Versions.props ("differentiate experimental insertions to avoid package id conflicts, it has to be alphabetically after 'preview'") encoded institutional knowledge that is now gone without a public trace.

Recommendation: Link the Roslyn PR/issue that proved this approach works (e.g., the equivalent Roslyn change), or open a GH discussion capturing the tradeoffs. This ensures the rationale is discoverable from the public repo history.

---

Summary

#	Dimension	Verdict
18	Documentation Accuracy	🟡 MODERATE
20	Scope & PR Discipline	🟡 MODERATE
10	Design Before Implementation	🔵 NIT
1–9, 11–17, 19, 21–24	All other dimensions	✅ LGTM

✅ 21/24 dimensions clean. No blocking issues.

Generated by Expert Code Review (on open) for #14277 · 978.9 AIC · ⊞ 30.4K · ◷

[github-actions]

Caution

agentic threat detected
Threat detection flagged this output in warn mode. Manual review is REQUIRED before any follow-up automation.

Details

The threat detection results could not be parsed.

Review the workflow run logs for details.

Code Review — Dim 18 (Documentation Accuracy) & Dim 20 (Scope & PR Discipline)

---

Dim 18 — Documentation Accuracy — ISSUE

Stale "Final-branded bits" in documentation/release.md timeline

After the diff, the Phase 4 timeline section reads:

* Before INSIDERS_SNAP_DATE — Phase 4
  - OptProf bootstrap
  - Final-branded bits land in VS main   ← still present, now inaccurate

The line - Final branding via \Stabilize-Release.ps1`was correctly removed, but the next bullet- Final-branded bits land in VS mainwas left untouched. The entire premise of this PR is that **pre-release** (not final-branded) versions are now inserted into VS. A person reading this timeline after the PR lands will encounter a direct contradiction: the script that produced final-branded bits is gone, yet the timeline still advertises those bits landing in VSmain`.

Concrete failing scenario: A release engineer consulting the timeline in release.md during Phase 4 reads "Final-branded bits land in VS main" and checks for stabilized packages in the VS insertion PR, finds only pre-release versions, and incorrectly concludes something went wrong.

Suggested fix:

  - Pre-release bits land in VS main

---

Dim 20 — Scope & PR Discipline — ISSUE

Acknowledged follow-up work has no tracking issue

The PR body states: "We still need to increment the VersionPrefix but now as part of the monthly release version update ... I will follow-up on that in a separate PR."

No linked issue tracks this follow-up. The monthly VersionPrefix cadence change is a meaningful process obligation — if it is not codified before the next release cycle, the team may produce packages whose version number never advances, causing confusion about what shipped. Untracked follow-up work in a PR that restructures an entire process is a discipline gap.

Suggested action: Open a tracking issue (or link an existing one) for "Codify monthly VersionPrefix increment as part of release checklist" before merging.

---

All other aspects of both dimensions are clean. The renumbering in release-checklist.md (4.3/4.6 → 4.4, new 4.3 warning text, artifacts table, and "4.4 was missed" cross-reference) is internally consistent. The SKILL.md heading (vs < 18.10 branches only) unambiguously excludes main. The PackageArtifacts/Release artifact path aligns with the UsingToolNuGetRepack>true addition. Scope is tight — all six files serve the single concern of removing the stabilization/final-branding requirement.

Generated by Expert Code Review (on open) for #14277 · 978.9 AIC · ⊞ 30.4K

[ViktorHofer]

I'm gonna merge this and try it out. We can always revert if we find issues.