Pipelines | Pre-compute all OneBranch package and file versions

[paulmedynski]

Makes the compute_versions stage the single source of every version the OneBranch build jobs consume, so nothing is re-derived downstream.

Remove the addRevision mode

Package versions had two mutually exclusive shapes. The revision shape (7.1.0.34430-preview1) is gone, along with the 16-bit wrapping of Build.BuildId, the four-part package base special case in both Versions.props files, and the addRevision queue-time parameter.

Worth noting the shape it removes was also a versioning hazard: a four-part core sorts above the stable release, so 7.1.0.34430-preview1 outranked 7.1.0 on the feed, and a four-part core with a prerelease tag isn't valid SemVer 2.0.

Move package version stamping into Versions.props

BuildSuffix now does what it always documented — it turns a stable base into a prerelease. Any version carrying a prerelease tag, from either the declared version or the suffix, is stamped with the build number; released versions are left exactly as declared.

NextVersion	BuildSuffix	Package version
7.1.0-preview3	— (OneBranch)	7.1.0-preview3.26238.3
7.1.0	— (release branch)	7.1.0
7.1.0-preview3	ci	7.1.0-preview3-ci.26238.3
7.1.0	ci	7.1.0-ci.26238.3
—	— (local dev)	7.1.0-preview3-dev

⚠️ PR/CI package versions gain a dot before the build number (-ci26238.3 → -ci.26238.3), because the old suffix path fused them. This is a deliberate improvement: SemVer splits the prerelease on dots, so the build number now compares numerically instead of lexically (previously …ci9 sorted above …ci10). No in-repo consumer string-matches the old form.

Pass pre-computed file versions into the build jobs

Build jobs received a raw build number and re-derived the file version through MSBuild. They now receive the file version the compute_versions stage already computed. build.proj gains opt-in FileVersionSqlClient / FileVersionSqlServer arguments, which emit nothing unless set — so PR/CI and local builds are unchanged.

This also fixes a latent bug: compute-versions.ps1 invoked the GetVersions* targets with a different build number than the build jobs used, then discarded the result and re-derived it in PowerShell.

Assembly version stays derived from the file version, as it's always major.0.0.0.

Fix SBOM metadata

globalSdl.sbom reported $(Build.BuildNumber) (e.g. 26238.3) as the version of a single hardcoded package name — a version matching no package produced, and used a single name for six different packages. Now it expands the SDL template with macro-expansion variables $(...) whose values are defined by each package's build job, and then interpolated for SBOM use. We are now using consistent package name/version values in each package's SBOM.

Testing

• Non-official OneBranch run 26250.2 succeeded; all build/pack stages consumed the expected package and file versions

[Copilot]

🟡 Changes recommended

Stable test-feed publishing can collide, and the moved version-shape logic lacks required automated coverage.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Centralizes OneBranch package/file version computation and corrects per-package SBOM metadata.

Changes:

• Removes revision-based versioning and standardizes SemVer stamping.
• Passes precomputed file versions through build and packaging jobs.
• Configures per-package SBOM identities and updates documentation/tests.

File summaries

File	Review
src/Microsoft.SqlServer.Server/Versions.props	Standardizes SqlServer version generation.
src/Microsoft.Data.SqlClient/Versions.props	Critical: Stable test-feed versions can collide on repeated publishes; retain exact production versions while making test releases build-specific.
eng/pipelines/onebranch/variables/package-variables.yml	Removes obsolete versioning guidance.
eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml	Passes precomputed file versions to analysis builds.
eng/pipelines/onebranch/steps/pack-buildproj-step.yml	Passes file versions during packaging.
eng/pipelines/onebranch/steps/build-buildproj-step.yml	Passes file versions during builds.
eng/pipelines/onebranch/stages/compute-versions-stage.yml	Simplifies canonical version computation.
eng/pipelines/onebranch/stages/build-stages.yml	Distributes computed versions to package jobs.
eng/pipelines/onebranch/sqlclient-official.yml	Removes revision mode and fixes SBOM metadata.
eng/pipelines/onebranch/sqlclient-non-official.yml	Mirrors official-pipeline version and SBOM changes.
eng/pipelines/onebranch/scripts/tests/compute-versions.Tests.ps1	Moderate: Add automated GetVersionsSqlClient and GetVersionsSqlServer coverage for stable/prerelease bases, with and without BuildSuffix.
eng/pipelines/onebranch/scripts/compute-versions.ps1	Emits canonical package and file versions.
eng/pipelines/onebranch/jobs/publish-symbols-job.yml	Disables irrelevant SBOM generation.
eng/pipelines/onebranch/jobs/build-buildproj-job.yml	Sets package-specific SBOM metadata.
build.proj	Adds file-version forwarding parameters.
.github/instructions/sqlclient-package-versions.instructions.md	Documents the new version shapes.
.github/instructions/onebranch-pipeline-design.instructions.md	Documents per-job SBOM configuration.

Review details

• Files reviewed: 17/17 changed files
• Comments generated: 2
• Review effort level: Balanced

---

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 64.00%. Comparing base (ce9f01b) to head (b79b45f).
⚠️ Report is 2 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (ce9f01b) and HEAD (b79b45f). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (ce9f01b)	HEAD (b79b45f)
CI-SqlClient	1	0

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4652      +/-   ##
==========================================
- Coverage   71.88%   64.00%   -7.89%     
==========================================
  Files         290      284       -6     
  Lines       45056    68006   +22950     
==========================================
+ Hits        32389    43527   +11138     
- Misses      12667    24479   +11812     

Flag	Coverage Δ
CI-SqlClient	?
PR-SqlClient-Project	64.00% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

🔵 Needs a closer look

Broad versioning and pipeline behavior changes require final human validation.

Review details

• Files reviewed: 20/20 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

🔵 Needs a closer look

Pipeline-wide versioning changes require human approval, and outdated version examples remain unresolved.

Review details

Suppressed comments (2)

build.proj:519

• The usage example immediately above this target is now outdated: with BuildNumber=1234, the updated Versions.props appends the build number to the prerelease package version, so the shown 7.1.0-preview1 output is no longer possible. Update the example to reflect the new target output.

      <_Cmd>"$(DotnetPath)dotnet" build "$(SqlClientProjectPath)" -getProperty:SqlClientPackageVersion $(BuildNumberArgument) $(BuildSuffixArgument) $(SqlClientNextVersionArgument)</_Cmd>

src/Microsoft.Data.SqlClient/Versions.props:78

• The new dot-separated prerelease shape is not reflected in the public build documentation. BUILDGUIDE.md:302-308 still says BuildSuffix=ci produces 1.2.3-ci1234, while this line now produces 1.2.3-ci.1234; build.proj:511-514 also still shows a prerelease version without the appended build number. Please update these canonical examples with the behavior change so contributors can predict the generated artifact names.

        <SqlClientPackageVersion Condition="$(_SqlClientCandidateVersion.Contains('-'))">$(_SqlClientCandidateVersion).$(BuildNumber)</SqlClientPackageVersion>

• Files reviewed: 18/18 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

🟡 Changes recommended

Explicit four-component package-version overrides currently generate invalid five-component file versions.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 18/18 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

🟡 Changes recommended

The new build and pack wrapper forwarding lacks direct regression coverage.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/Microsoft.Data.SqlClient/Versions.props:79

• The new separator leaves the repository's versioning documentation inconsistent with the implementation: BUILDGUIDE.md:308 still documents 1.2.3-ci1234, Directory.Packages.props:46 uses preview1-ci123, and .github/instructions/ado-pipelines.instructions.md:108 describes a different old ordering. Since this changes every PR/CI package version, update those references to the new -ci.<BuildNumber> / -pr.<BuildNumber> shape in this PR.

• Files reviewed: 18/18 changed files
• Comments generated: 1
• Review effort level: Balanced

[priyankatiwari08]

Version-shape consolidation looks correct; Versions.props global-property override makes the pre-computed file version win as intended. Two things:

• globalSdl.sbom now indirects through $(sbomPackageName)/$(sbomPackageVersion), but only build-buildproj-job.yml sets them. publish-nuget-package-job.yml sets ob_outputDirectory: $(JOB_OUTPUT) and neither defines those variables nor sets ob_sdl_sbom_enabled: false, so its SBOM will carry the literal unresolved macros. validate-signed-package-job.yml has the same gap.
• FileVersionSqlClient/FileVersionSqlServer are now pipeline-supplied inputs but only rejected when they have 5+ numeric components — see inline.

[Copilot]

🟡 Changes recommended

Moderate file-version compatibility and target-scope documentation issues remain unresolved.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (5)

build.proj:140

• This scope is broader than the implementation: FileVersionSqlClientArgument is forwarded only by the SqlClient-family Build and Pack targets, not by the Test targets included in PackageVersionSqlClient's scope above. Document the actual target set so callers do not expect the wrapper to affect test-triggered builds.

      FileVersionSqlClient
      Applies to:     The same targets as PackageVersionSqlClient.

build.proj:187

• This scope is broader than the implementation: FileVersionSqlServerArgument is forwarded only by BuildSqlServer and PackSqlServer, while PackageVersionSqlServer also applies to SqlClient consumer and test targets. Document the actual target set so callers do not expect this wrapper to stamp those targets.

      FileVersionSqlServer
      Applies to:     The same targets as PackageVersionSqlServer.

src/Microsoft.Data.SqlClient/Versions.props:112

• The new check validates component count but not the required 16-bit range: 1.2.3.65536 matches this regex even though src/Directory.Build.props:116-120 documents the file-version component as unsigned 16-bit. Since source builds treat warnings as errors, that input bypasses this diagnostic and fails later with the less useful compiler error. Validate each component's range as well and cover an out-of-range value in the tests.

      Condition="!$([System.Text.RegularExpressions.Regex]::IsMatch('$(SqlClientFileVersion)', '^\d+\.\d+\.\d+\.\d+$'))"

src/Microsoft.Data.SqlClient/Versions.props:78

• The new dotted prerelease shape is implemented here, but contributor-facing examples still advertise the removed fused form: BUILDGUIDE.md:308 shows 1.2.3-ci1234, and Directory.Packages.props:46 uses preview1-ci123. Update those examples to include the separator so local and CI consumers follow the canonical format.

        <SqlClientPackageVersion Condition="$(_SqlClientCandidateVersion.Contains('-'))">$(_SqlClientCandidateVersion).$(BuildNumber)</SqlClientPackageVersion>

src/Microsoft.SqlServer.Server/Versions.props:108

• The new check validates component count but not the required 16-bit range: 1.2.3.65536 matches this regex even though src/Directory.Build.props:116-120 documents the file-version component as unsigned 16-bit. Since source builds treat warnings as errors, that input bypasses this diagnostic and fails later with the less useful compiler error. Validate each component's range as well and cover an out-of-range value in the tests.

      Condition="!$([System.Text.RegularExpressions.Regex]::IsMatch('$(SqlServerFileVersion)', '^\d+\.\d+\.\d+\.\d+$'))"

• Files reviewed: 20/20 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

🟡 Changes recommended

Version examples and build.proj option-scope documentation must be corrected.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (2)

build.proj:187

• This does not actually apply to all targets listed for PackageVersionSqlServer: the new argument is forwarded only by BuildSqlServer and PackSqlServer, not by SqlClient build/pack or test targets that consume the package-version override. Document the actual scope so callers do not rely on an ignored option.

      Applies to:     The same targets as PackageVersionSqlServer.

build.proj:140

• The stated scope is broader than the implementation: PackageVersionSqlClient applies to several Test* targets, but FileVersionSqlClientArgument is only forwarded by the SqlClient-family build and pack targets. Since this option is intended for build-job stamping, narrow the documented scope rather than promising that test targets consume it.

      Applies to:     The same targets as PackageVersionSqlClient.

• Files reviewed: 20/20 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

🔵 Needs a closer look

Cross-cutting versioning, pipeline, and SBOM changes require final human review.

Review details

• Files reviewed: 20/20 changed files
• Comments generated: 0 new
• Review effort level: Balanced