Restore the preview package version convention used by earlier releases

[priyankatiwari08]

Fixes the package version convention regression introduced when versioning was consolidated into Versions.props.

Problem

Preview packages up to and including 7.1.0-preview2 shipped as {base}-{suffix}.{Build.BuildNumber}, with a date-encoded file version:

	Package version	File version
7.1.0-preview2 (shipped)	7.1.0-preview2.26190.5	7.1.0.26190

After #4336 moved version selection out of the pipeline YAML, compute-versions.ps1 can only emit two shapes, and neither reproduces the shipped convention:

addRevision	Package version	File version
false (default)	7.1.0-preview3	7.1.0.38305
true	7.1.0.38995-preview3	7.1.0.38995

Two things changed at once:

1. The revision moved ahead of the prerelease suffix (Add-VersionRevision rebuilds the version as {base}.{revision}-{suffix}).
2. Its source changed from $(Build.BuildNumber) to $(Build.BuildId). Because the official pipeline passes that revision through as -p:BuildNumber, the file version also lost its date encoding — 38305 is just build id 169375 wrapped through 16 bits.

Confirmed against the shipped assemblies:

preview2  FileVersion 7.1.0.26190  ProductVersion 7.1.0-preview2.26190.5+52ed94b1
preview3  FileVersion 7.1.0.38305  ProductVersion 7.1.0-preview3+c16adb7a

Change

Restore the original shape for OneBranch runs, without disturbing the CI or local-dev paths (which use BuildSuffix and are unaffected):

• Pass $(Build.BuildNumber) into compute-versions.ps1.
• When addRevision is false, append the build number after the prerelease suffix, and emit the build number's date segment as VersionRevision so the downstream -p:BuildNumber yields 7.1.0.26238.
• Leave stable versions unstamped, matching the previous behaviour where only preview builds carried a build number.
• Leave the addRevision path untouched, so repeated test publishes can still disambiguate by build id.

Result

	Package version	File version	Assembly version
7.1.0-preview2 (shipped)	7.1.0-preview2.26190.5	7.1.0.26190	7.0.0.0
7.1.0-preview3 before	7.1.0-preview3	7.1.0.38305	7.0.0.0
7.1.0-preview3 after	7.1.0-preview3.26238.3	7.1.0.26238	7.0.0.0

Verification

compute-versions.ps1 run end-to-end against a stubbed dotnet via its -DotnetPath test hook:

AddRevision=false  ->  SqlClient 7.1.0-preview3.26238.3   VersionRevision 26238
AddRevision=true   ->  SqlClient 7.1.0.42-preview3        VersionRevision 42
buildSqlServer=false, AddRevision=false -> SqlServer 1.0.0 (published, unstamped)

MSBuild property evaluation of the real Versions.props:

-p:SqlClientPackageVersion=7.1.0-preview3        -p:BuildNumber=38305  ->  FileVersion 7.1.0.38305
-p:SqlClientPackageVersion=7.1.0-preview3.26238.3 -p:BuildNumber=26238 ->  FileVersion 7.1.0.26238

Pester coverage updated: build-number stamping, unbuilt-SqlServer passthrough, and stable versions left unstamped.

Checklist

• Tests added or updated
• Public API changes documented — n/a, no public API change
• Verified against customer repro (if applicable) — verified against the shipped preview2 package and assembly
• Ensure no breaking changes introduced — assembly version stays 7.0.0.0; CI, PR and local-dev version paths are untouched

/cc @paulmedynski @cheenamalhotra

[Copilot]

Pull request overview

Restores historical OneBranch preview package and file-version stamping.

Changes:

• Appends pipeline build numbers to prerelease package versions.
• Preserves build-ID revisioning as an opt-in path.
• Expands Pester coverage for versioning scenarios.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
compute-versions-stage.yml	Passes the pipeline build number.
compute-versions.ps1	Implements restored version stamping.
compute-versions.Tests.ps1	Tests preview, stable, and SqlServer behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[priyankatiwari08]

Test evidence for the latest push (c178edd60).

Worth flagging that nothing in CI executes these Pester tests. There is no pipeline stage, GitHub workflow, or build.proj target that references eng/pipelines/onebranch/scripts/tests/, so they only ever run when someone runs them by hand. I ran the full suite locally against this branch:

Pester v5.7.1 / PowerShell 7.6.5

Describing compute-versions.ps1 Effective Versions
  [+] appends the build number after the prerelease suffix when package revisioning is disabled
  [+] inserts the revision before prerelease suffixes for built packages
  [+] retains the published SqlServer package when SqlServer is not built
  [+] wraps revisions above 65535 and logs the mapping as information
  [+] emits the build number rather than the wrapped revision when package revisioning is disabled
  [+] retains the published SqlServer package unstamped when SqlServer is not built
  [+] omits the build number from non-preview package versions when package revisioning is disabled
  [+] revises non-preview package versions when package revisioning is enabled

Describing compute-versions.ps1 Error Handling
  [+] rejects a non-positive revision
  [+] requires a build number when package revisioning is disabled
  [+] rejects a malformed build number
  [+] throws when a GetVersions target fails
  [+] throws when required version labels are absent
  [+] throws when a revised package does not have a three-part numeric base

Tests Passed: 14, Failed: 0

Whole directory including publish-symbols.Tests.ps1: Passed=36, Failed=0

Two environment notes for anyone else trying to run them, since neither is obvious from the README:

• They require PowerShell 7. Line 7 uses the three-argument form of Join-Path, which only exists in PowerShell 6+, so the file fails at discovery under Windows PowerShell 5.1 no matter which Pester is loaded.
• They require Pester 5, not 6. Under Pester 6 both files in this directory fail with a labelled-break error during discovery. That is pre-existing and not specific to this change, but it means Install-Module Pester -MinimumVersion 5.0 as written in the README now resolves to a version that cannot run them.

Happy to add a follow-up that wires this directory into CI and pins the Pester version, if that is wanted. It felt out of scope here.

I also confirmed this push does not change any emitted version. Running the pre-review-feedback script and the current one with the exact arguments the stage passes produces identical output, apart from the suppressed wrap warning:

##vso[task.setvariable variable=SqlClientPackageVersion;isOutput=true]7.1.0-preview3.26238.1
##vso[task.setvariable variable=SqlServerPackageVersion;isOutput=true]1.1.0-preview1.26238.1
##vso[task.setvariable variable=VersionRevision;isOutput=true]26238

[priyankatiwari08]

Scope note

This PR is a release blocker for 7.1.0-preview3, so I want to be explicit about what I am and am not taking on here.

In scope: restoring the package and file version convention we shipped in preview2. That is the addRevision: false path, which is what both pipelines default to and what preview3 will actually build with.

Preview2 shipped, and preview3 currently does not:

	preview2 (shipped)	preview3 on main today	this PR
Package version	7.1.0-preview2.26190.5	7.1.0.38995-preview3	7.1.0-preview3.26238.1
FileVersion	7.1.0.26190	7.1.0.38995	7.1.0.26238
AssemblyVersion	7.0.0.0	7.0.0.0	7.0.0.0

The regression came in with #4336 and was not deliberate. Three of the four version fields moved, and the file version stopped carrying the date encoding. Validated end to end on non-official run 26238.1, and the produced package matches preview2's shape on every field.

Deferred: anything that is a genuine improvement but not required to get preview3 out. I have filed #4603 for these rather than dropping them:

• whether the addRevision: true shape should exist at all
• wiring the versioning Pester tests into CI and pinning Pester 5
• Get-CanonicalVersions passing a build number that cannot apply on the false path

I would rather land the narrow fix, ship preview3, and do those properly than widen this PR while the release is blocked. If anything I have deferred looks like it actually is required for correctness here, say so and I will pull it back in.

Review feedback addressed so far

Reviewer	Ask	Status
@paulmedynski	Missing non-preview test cases	Added
@paulmedynski	Note that BuildNumber is ignored when AddRevision is true	Added
@paulmedynski	Mandatory parameter that is sometimes ignored	Now optional, validated, with an explicit error when required
@paulmedynski	Rewrite .DESCRIPTION	Rewritten (one open question below)
@benrr101	Hard-coded build number in tests	Hoisted to a documented constant, assertions derived from it
Copilot	Update the package-versions instructions	Updated
Copilot	Gate the 16-bit wrap warning	Gated
@cheenamalhotra	Why support the 1.2.3.<revision>-previewX format	Answered, deferred to #4603

One open question for @paulmedynski: your suggested wording used 1.2.3-previewX-<build_number> with a hyphen, but preview2 actually shipped 7.1.0-preview2.26190.5 with a dot. I used the dot. Please confirm the hyphen was a typo.

Tests are 14/14 locally on pwsh 7.6.5 with Pester 5.7.1.

[benrr101]

it'll probably work

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[paulmedynski]

Approving, and we can address the outstanding comments in followup work.