Consolidate and align SqlClient versioning - #4336
Conversation
paulmedynski
added
the
Area\Engineering
paulmedynski
changed the title
paulmedynski
changed the title
There was a problem hiding this comment.
Pull request overview
This PR introduces a centralized “compute versions” stage for CI/PR pipelines (mirroring the OneBranch approach) and refactors version sources so pipelines can compute/package versions once and flow them to downstream stages/jobs.
Changes:
- Added
compute_versions_cistage to extract package/file versions up-front via newGetVersions*targets inbuild.proj. - Refactored each package’s
Versions.propsto introduce*NextVersionand*PublishedVersionproperties. - Began wiring CI/PR and OneBranch pipelines/templates to consume computed versions (but the current wiring is incomplete and will break pipeline execution).
Reviewed changes
Copilot reviewed 33 out of 33 changed files in this pull request and generated 12 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Microsoft.SqlServer.Server/Versions.props | Adds Published/Next version properties; updates computed package/file version logic to use SqlServerNextVersion. |
| src/Microsoft.Data.SqlClient/Versions.props | Adds Published/Next version properties; updates computed package/file version logic to use SqlClientNextVersion. |
| src/Microsoft.Data.SqlClient.Internal/Logging/src/Versions.props | Adds Published/Next version properties; updates computed package/file version logic to use LoggingNextVersion. |
| src/Microsoft.Data.SqlClient.Extensions/Azure/src/Versions.props | Adds Published/Next version properties; updates computed package/file version logic to use AzureNextVersion. |
| src/Microsoft.Data.SqlClient.Extensions/Abstractions/src/Versions.props | Adds Published/Next version properties; updates computed package/file version logic to use AbstractionsNextVersion. |
| src/Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider/src/Versions.props | Adds Published/Next version properties; updates computed package/file version logic to use AkvProviderNextVersion. |
| eng/pipelines/stages/compute-versions-ci-stage.yml | New CI/PR stage that runs GetVersions* targets and exports versions as stage/job outputs. |
| eng/pipelines/stages/build-sqlserver-package-ci-stage.yml | Adds dependency on compute stage and maps its outputs to stage variables (but needs additional wiring updates). |
| eng/pipelines/stages/build-sqlclient-package-ci-stage.yml | Adds dependency on compute stage and maps its outputs to stage variables; attempts to use those versions downstream. |
| eng/pipelines/stages/build-logging-package-ci-stage.yml | Adds dependency on compute stage and maps its outputs to stage variables (but needs downstream job wiring updates). |
| eng/pipelines/stages/build-azure-package-ci-stage.yml | Adds dependency on compute stage and maps its outputs to stage variables (but downstream job calls still use template parameters). |
| eng/pipelines/stages/build-abstractions-package-ci-stage.yml | Adds dependency on compute stage and maps its outputs to stage variables (but downstream job calls still use template parameters). |
| eng/pipelines/sqlclient-pr-project-ref-pipeline.yml | Passes buildSuffix: 'pr' into the CI core template. |
| eng/pipelines/sqlclient-pr-package-ref-pipeline.yml | Passes buildSuffix: 'pr' into the CI core template. |
| eng/pipelines/dotnet-sqlclient-ci-project-reference-pipeline.yml | Passes buildSuffix: 'ci' into the CI core template. |
| eng/pipelines/dotnet-sqlclient-ci-package-reference-pipeline.yml | Passes buildSuffix: 'ci' into the CI core template. |
| eng/pipelines/dotnet-sqlclient-ci-core.yml | Adds buildSuffix parameter and injects the compute-versions stage before other stages. |
| eng/pipelines/libraries/ci-build-variables.yml | Removes previously hardcoded per-package version variables in favor of computed versions. |
| build.proj | Adds GetVersions* targets that emit labeled version lines for pipeline parsing. |
| eng/pipelines/onebranch/variables/package-variables.yml | Removes OneBranch per-package version variables; keeps artifact naming variables. |
| eng/pipelines/onebranch/stages/compute-versions-stage.yml | New OneBranch stage to compute “next/published/effective” versions and emit output variables. |
| eng/pipelines/onebranch/stages/build-stages.yml | Refactors build template to require pre-computed versions; comments out SqlClient package validation stage. |
| eng/pipelines/onebranch/stages/publish-symbols-stage.yml | Refactors parameters to require pre-computed package versions for symbol publishing. |
| eng/pipelines/onebranch/stages/release-stages.yml | Removes explicit per-version packagePath in favor of default/wildcarded publish behavior. |
| eng/pipelines/onebranch/jobs/build-buildproj-job.yml | Threads “pre-computed version” concept through build/pack steps; tweaks APIScan versionNumber handling. |
| eng/pipelines/onebranch/jobs/publish-symbols-job.yml | Refactors job variables to list form; clarifies version requirement. |
| eng/pipelines/onebranch/steps/roslyn-analyzers-buildproj-step.yml | Updates comments to reflect version must be pre-computed. |
| eng/pipelines/onebranch/steps/pack-buildproj-step.yml | Updates comments to reflect version must be pre-computed. |
| eng/pipelines/onebranch/steps/build-buildproj-step.yml | Updates comments to reflect version must be pre-computed. |
| eng/pipelines/onebranch/sqlclient-official.yml | Removes passing version vars to templates (but does not yet provide new required version parameters). |
| eng/pipelines/onebranch/sqlclient-non-official.yml | Removes passing version vars to templates (but does not yet provide new required version parameters). |
| .github/instructions/sqlclient-package-versions.instructions.md | New documentation describing version resolution flow (examples need to match actual pipeline build-number format). |
| .github/instructions/3rd-party-package-versions.instructions.md | Renames/re-scopes instructions to explicitly cover third-party dependency versions. |
756dc7a to
e63eafa
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4336 +/- ##
==========================================
- Coverage 64.71% 62.81% -1.91%
==========================================
Files 288 283 -5
Lines 44088 67041 +22953
==========================================
+ Hits 28532 42112 +13580
- Misses 15556 24929 +9373
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
- compute-versions (CI + OneBranch): install the global.json-pinned .NET SDK and restore dotnet tools before 'dotnet build'; fail fast if version extraction yields an empty value; add 'set -euo pipefail' to the resolve step. (review: #8, #9, #10, #12, #13, #14) - build-buildproj-job: use an explicit non-empty check for package.artifactName in the compile-time 'if'; drop the no-op coalesce for the APIScan file version (OneBranch always supplies one). (review: #15, #25) - compute-versions: document that a boolean ${{ }} parameter renders the PascalCase 'True'/'False', so comparing to 'True' is correct. (review: #24) - publish-nuget-package-job: correct the stale packagePath comment (packages/ -> Package-Release/) and note coalesce() skips the empty default. (review: #16-#21) - docs: sqlclient-package-versions.instructions.md uses buildSqlServer, not releaseSqlServer. (review: #27)
…eline cleanup
- Directory.Packages.props: clarify only the SqlServer Versions.props is imported here; the SqlClient family file comes from src/Directory.Build.props
- src/Microsoft.Data.SqlClient/Versions.props: drop stale claim that Directory.Packages.props imports this file
- onebranch build/pack-buildproj-step.yml: remove obsolete comment block (also fixes 'againast' typo)
- onebranch compute-versions-stage.yml: avoid literal empty ${{ }} in a script-block comment that ADO evaluated as a template expression
17a911d to
c78ee0f
Compare
benrr101
left a comment
benrr101
left a comment
There was a problem hiding this comment.
Overall, I think this is doing exactly what I envisioned. My only requests are 1) see if you agree with any of my points, 2) see if we can reduce the amount of special casing required in the pipelines.
| // Look for the PackageVersion field, falling back to FileVersion. | ||
| var field = type.GetField( | ||
| "NuGetPackageVersion", | ||
| "PackageVersion", |
There was a problem hiding this comment.
nit:
var field = type.GetField("PackageVersion", BindingFlags.NonPublic | BindingFlags.Static)
?? type.GetField("FileVersion", BindingFlags.NonPublic | BindingFlags.Static);There was a problem hiding this comment.
Updated this to the compact null-coalescing lookup. The assignment wraps after = to respect the existing line length. Validated with a net8.0 Stress Runner build. Local commit: 9252526ba.
| Directory.Packages.props imports all Versions.props early in Package mode; the guard | ||
| prevents each csproj's own conditional import from re-importing and re-evaluating | ||
| version properties. | ||
| src/Directory.Build.props imports this file for every project; the guard prevents re-importing |
There was a problem hiding this comment.
What harm is caused by re-importing and re-evalating the properties?
There was a problem hiding this comment.
I tested this by forcing the import guard off. MSBuild emits warning MSB4011, describes the duplicate as a likely build-authoring error, and ignores the subsequent import, so it does not re-evaluate the properties. I kept the guards to avoid that warning and updated the comments to describe the behavior accurately. Local commit: 9252526ba.
| <!-- | ||
| This is the *next* version to release of SqlServer. Update this when the next version is | ||
| decided. | ||
| @TODO: Determine how versions should be updated in release branches vs main |
There was a problem hiding this comment.
This note can probably be deleted. I think you figured it out :)
There was a problem hiding this comment.
Removed the TODO and replaced it with the concrete instruction to update SqlServerNextVersion after each release. Local commit: 9252526ba.
| Applies to: TestSqlClient, TestSqlClientFunctional, TestSqlClientManual | ||
| BuildAkvProvider, PackAkvProvider | ||
| TestAzure | ||
| Applies to: BuildSqlClient*, PackSqlClient, BuildLogging, PackLogging, BuildAbstractions, |
There was a problem hiding this comment.
Something here doesn't sit right with me. Maybe if we could have them grouped by Build / Pack / Test? I dunno.
I'm also wondering how much of these do actually apply regardless of reference type.
There was a problem hiding this comment.
Grouped the applicability lists into Build, Pack, and Test, and clarified the reference-mode distinction: Build and Pack use the family version in both modes, while Test consumes it only in Package mode. I also corrected the SqlServer target list. Local commit: 9252526ba.
|
|
||
| variables: | ||
| - name: sqlClientPackageVersion | ||
| value: $[ stageDependencies.compute_versions.compute_versions_job.outputs['versions.SqlClientPackageVersion'] ] |
There was a problem hiding this comment.
I was hoping we could avoid using the $[ ] syntax. It's hard enough to understand what ${{ }} and $( ) do 😅
| dependencies: | ||
| - artifactName: '${{ parameters.abstractionsArtifactsName }}' | ||
| shortName: 'Abstractions' | ||
| version: '$(sqlClientPackageVersion)' |
There was a problem hiding this comment.
If we can, I think we should be using ${{ variables.sqlClientPackageVersion }} so it's clear where it's coming from
There was a problem hiding this comment.
This value comes from a $[ stageDependencies... ] runtime output. ${{ variables.sqlClientPackageVersion }} is evaluated during template expansion before that output exists, so it would not carry the computed version. I also audited the other macros in this stage; they are runtime stage outputs or predefined runtime paths, so there are no safe promotions here.
| # Extract versions (package, published, file) for the SqlClient family | ||
| # (GetVersionsSqlClient) and Microsoft.SqlServer.Server (GetVersionsSqlServer). | ||
| # Each target emits labeled messages to stdout. | ||
| - script: | |
There was a problem hiding this comment.
Minor concern here that using script implicitly means bash, which makes this stage non-portable. While above, we use pwsh which is portable.
There was a problem hiding this comment.
Converted both version extraction and effective-version resolution blocks from implicit Bash script steps to portable pwsh steps. I validated the PowerShell parsing against both real GetVersions targets and both next/published values. Local commit: 9252526ba.
| # Provider) and PackageVersionSqlServer (Microsoft.SqlServer.Server). Provided by the caller. | ||
| # Examples: 'SqlClient' -> -p:PackageVersionSqlClient=7.1.0-preview3 | ||
| # 'SqlServer' -> -p:PackageVersionSqlServer=1.0.0 | ||
| - name: versionPropertySuffix |
There was a problem hiding this comment.
I would like to see this derived from the packageShortName if possible.
There was a problem hiding this comment.
A direct derivation only works for SqlServer and SqlClient: short names such as Logging, Abstractions, and Azure all use the shared PackageVersionSqlClient property rather than matching properties of their own. I moved that two-family mapping to explicit caller metadata, so this step and the shared job remain generic. Local commit: 9252526ba.
| -p:PackageVersion${{ parameters.packageShortName }}="${{ parameters.packageVersion }}" | ||
| -p:BuildNumber=$(Build.BuildNumber) | ||
| ${{ parameters.dependencyArguments }} | ||
| -p:PackageVersion${{ parameters.versionPropertySuffix }}=${{ parameters.packageVersion }} |
There was a problem hiding this comment.
I ... uh ... what? Nit: can this be kept next to the BuildNumber parameter? I tried to keep the versioning properties next to each other since they version the package being built rather than the dependencies.
There was a problem hiding this comment.
Moved the package-version argument directly beside BuildNumber. I applied the same ordering to the analyzer, build, and pack commands for consistency. Local commit: 9252526ba.
github-project-automation
Bot
moved this from In review
to Waiting for customer
in SqlClient Board
Replace the generated InformationalVersion/NuGetPackageVersion constants with FileVersion/PackageVersion and update all consumers (diagnostics, user agent, Azure extension, stress runner, and unit tests).
Replace the per-project Versions.props files for the AKV provider, Abstractions, Azure, and Logging packages with a single shared family version. Wire the consuming csproj files, nuspec, central package props, and build.proj version arguments to the unified version.
Add a compute-versions CI stage and thread the unified family version through the legacy Azure DevOps CI and PR pipelines (build/pack/test stages, jobs, steps, and shared templates).
48e55ef to
3af74e1
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 67 out of 67 changed files in this pull request and generated no new comments.
Suppressed comments (2)
.github/instructions/onebranch-pipeline-design.instructions.md:94
- The OneBranch pipeline design doc still lists the removed
isPreviewbuild parameter and does not mention the newaddRevisionparameter introduced by this PR. It also leaves the subsequent paragraph and bullets (below this changed region) describing the oldisPreview/effective*Versionvariable model, which no longer matches the new Versions.props + compute-versions-stage flow.
Build parameters:
- `debug` — enable debug output (default `false`)
- `isPreview` — use preview version numbers (default `false`)
- `publishSymbols` — publish symbols to servers (default `false`)
- `buildSqlServer` — build the Microsoft.SqlServer.Server package (default `true` in the non-official/nightly pipeline, `false` in the official pipeline). The SqlClient family is always built, so this is the only build toggle. It also drives the SqlServer dependency version the family uses (built/next vs published). Requesting `releaseSqlServer` without `buildSqlServer` fails template expansion.
build.proj:97
- This comment describing which packages are in the SqlClient family omits
Microsoft.Data.SqlClientitself. Since the family version applies to SqlClient too, the list should include it for clarity/accuracy.
The Internal.Logging, Extensions.Abstractions, Extensions.Azure, and
AlwaysEncrypted.AzureKeyVaultProvider packages are all part of the SqlClient family and share
the SqlClient version. There are no longer separate per-package version parameters for these
packages — use PackageVersionSqlClient (below) to set the version for the entire family.
-->
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 67 out of 67 changed files in this pull request and generated no new comments.
Suppressed comments (1)
src/Microsoft.Data.SqlClient/tests/StressTests/SqlClient.Stress.Runner/Program.cs:262
- The stress runner previously supported multiple generations of ThisAssembly field names (NuGetPackageVersion / InformationalVersion) to remain compatible when the referenced Microsoft.Data.SqlClient assembly differed. With the rename to PackageVersion/FileVersion, this now only probes the new field names, so running the updated runner against an older SqlClient assembly will return "" instead of a version.
78b3f74 to
dc7cb54
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 67 out of 67 changed files in this pull request and generated no new comments.
Suppressed comments (3)
.github/instructions/onebranch-pipeline-design.instructions.md:101
- This file still contains a later paragraph describing how
isPreviewaffectseffective*Versionvariables, but the OneBranch pipelines in this PR removedisPreviewand compute preview/GA purely fromVersions.props. That paragraph should be updated to avoid misleading guidance.
Official-only parameter:
- `releaseToProduction` — controls both NuGet target feed and symbol server destination (default `false`):
.github/instructions/onebranch-pipeline-design.instructions.md:93
- The OneBranch pipeline design doc still references the removed
isPreviewparameter (and its related preview/GA resolution text). This makes the instructions inaccurate for contributors and risks misconfiguring pipeline runs.
This issue also appears on line 100 of the same file.
Build parameters:
- `debug` — enable debug output (default `false`)
- `isPreview` — use preview version numbers (default `false`)
- `publishSymbols` — publish symbols to servers (default `false`)
eng/pipelines/onebranch/scripts/tests/compute-versions.Tests.ps1:40
- The local dotnet mock output includes a
PublishedVersion:line for the SqlClient family, butGetVersionsSqlClientonly emitsPackageVersion:andFileVersion:(PublishedVersion is SqlServer-only). Keeping the extra label in the mock can hide parser/test regressions and confuses the contract being validated.
return @(
' PackageVersion: 7.1.0-preview3'
' PublishedVersion: 7.0.0'
" FileVersion: 7.1.0.$global:computeVersionsFileRevision"
)
| @TODO: Determine how versions should be updated in release branches vs main | ||
| --> | ||
| <SqlServerVersionDefault>1.0.0</SqlServerVersionDefault> | ||
| <SqlServerNextVersion>1.1.0-preview1</SqlServerNextVersion> |
There was a problem hiding this comment.
won't this cause the next release to rely on an unpublished sqlserver version?
Add a compute-versions stage that resolves a single SqlClient family version and a single Microsoft.SqlServer.Server version up front, and thread them through the OneBranch official and non-official pipelines (build/publish/release stages, jobs, steps, and package variables). Each package is built, analyzed, and packed with the correct build.proj package-version property -- PackageVersionSqlClient for the whole SqlClient family and PackageVersionSqlServer for Microsoft.SqlServer.Server. Family packages that depend on Microsoft.SqlServer.Server pin it to the computed SqlServer version (freshly built this run, or the last published version otherwise); shared family dependencies need no explicit pin, since PackageVersionSqlClient covers them.
Add the sqlclient-package-versions instructions, rename the package-versions instructions to 3rd-party-package-versions, refresh the OneBranch pipeline design notes, and update BUILDGUIDE for the unified version model.
dc7cb54 to
dac28e8
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 67 out of 67 changed files in this pull request and generated no new comments.
Suppressed comments (1)
.github/instructions/onebranch-pipeline-design.instructions.md:94
- onebranch-pipeline-design.instructions.md still documents an
isPreviewpipeline parameter and preview/GA version-selection behavior, but the OneBranch entry pipelines in this PR removeisPreviewand compute versions via the compute-versions stage / canonical Versions.props. The doc should be updated so it matches the pipeline surface area and the new versioning flow.
Build parameters:
- `debug` — enable debug output (default `false`)
- `isPreview` — use preview version numbers (default `false`)
- `publishSymbols` — publish symbols to servers (default `false`)
- `buildSqlServer` — build the Microsoft.SqlServer.Server package (default `true` in the non-official/nightly pipeline, `false` in the official pipeline). The SqlClient family is always built, so this is the only build toggle. It also drives the SqlServer dependency version the family uses (built/next vs published). Requesting `releaseSqlServer` without `buildSqlServer` fails template expansion.
Overall goal
Make package version specification and computation simple, centralized, and unambiguous:
PackageVersion,FileVersion,AssemblyVersion) is specified/computed in exactly one place — once for the entire SqlClient family and once forMicrosoft.SqlServer.Server.Microsoft.Data.SqlClient,Internal.Logging,Extensions.Abstractions,Extensions.Azure, and the AlwaysEncryptedAzureKeyVaultProvideralways share one version (package, file, and assembly) and release together.Microsoft.SqlServer.Serveris versioned and released independently.AssemblyFileVersionproperty and use only the unambiguous SDK termsFileVersion(Major.Minor.Patch.Revision) andAssemblyVersion(Major.0.0.0).Why one PR with several large commits (not one PR per commit)
This is a single cross-cutting change to how versions flow through projects, build orchestration, and three pipeline families. The pieces share tight, bidirectional contracts, so splitting them into independently-mergeable PRs would mean writing throwaway scaffolding (temporary shims, dual code paths, and compatibility aliases) purely to keep
maingreen between merges — strictly more total work that we would then have to unwind. The commits are instead structured so a reviewer can read one logical body of work at a time, while the PR merges atomically. Concrete examples of the interdependencies:dotnet build build.proj -t:GetVersionsSqlClient/GetVersionsSqlServerand parse aPackageVersion:/FileVersion:stdout contract. Those targets and that stdout format are introduced in the build commit. A standalone "pipeline" PR would invoke targets that don't exist onmain; a standalone "build.proj" PR would delete the old per-packageGetVersions*targets that the current pipelines still call — breaking CI onmainthe moment it merged.stageDependencies.compute_versions_ci.compute_versions_job.outputs['versions.SqlClientPackageVersion']and feed it into thePackageVersionSqlClientbuild argument. The producing stage (pipeline commit) and the consuming argument (build commit) are only meaningful together; neither half is correct alone.Versions.propsfiles and adds the singleDirectory.Build.propsimport of the familyVersions.props. Done separately, one ordering leaves family projects with no version defined, and the other leaves duplicate/conflicting version definitions — so they cannot be reviewed/merged as independently-correct units.ThisAssembly.InformationalVersion/NuGetPackageVersionconstants without simultaneously updating the six consumers (AdapterUtil,SqlDiagnosticListener,UserAgent, the Azure auth provider,UserAgentTests, the stress runner) fails to compile. Even this "small" change is irreducible — which is exactly why it is one commit, not one-PR-per-file.Commits (review order)
The branch began with five logical commits and now includes three focused follow-up commits. Each is a single coherent body of work; they are intended to be reviewed in order. Individual commits are not guaranteed to build/test in isolation (see above).
1. Rename
ThisAssemblyversion constants toFileVersionandPackageVersionA self-contained refactor that removes the ambiguous version naming. In
tools/targets/GenerateThisAssemblyCs.targetsthe generatedThisAssemblyconstants are renamed:InformationalVersion→FileVersionandNuGetPackageVersion→PackageVersion. All consumers are updated:AdapterUtil,SqlDiagnosticListener,UserAgent, the AzureActiveDirectoryAuthenticationProvider,UserAgentTests, and the reflection-based stress runner. (7 files)2. Unify SqlClient family packages onto a single shared version
The core project/build change. The four per-package family
Versions.propsfiles (AKV provider, Abstractions, Azure, Logging) are deleted.src/Microsoft.Data.SqlClient/Versions.propsbecomes the single source of truth for the family (SqlClientPackageVersion,SqlClientFileVersion,SqlClientAssemblyVersion);src/Microsoft.SqlServer.Server/Versions.propsstays independent.src/Directory.Build.propsimports the familyVersions.propsfor every project,Directory.Packages.propspins family packages to the shared range, and all family.csprojfiles plus the nuspec consume the shared properties.build.projcollapses the per-packageGetVersions*targets toGetVersionsSqlClientandGetVersionsSqlServer, with a singlePackageVersionSqlClientparameter (old per-package arguments kept as aliases). (15 files)3. Compute SqlClient family versions centrally in CI/PR pipelines
Adds
eng/pipelines/stages/compute-versions-ci-stage.yml, which runs the twoGetVersions*targets with aBuildSuffixand emits the family + SqlServer versions. All family build/test/pack stages, jobs, steps, and shared templates take a dependency on the new stage and map their version variables from the sharedSqlClient*outputs. CI version parameters are consolidated onto a singlepackageVersionparameter (Microsoft.SqlServer.Serverkeeps its own); PR pipelines passbuildSuffix: pr, CI pipelines passbuildSuffix: ci. (25 files)4. Compute SqlClient family versions centrally in OneBranch pipelines
Adds
eng/pipelines/onebranch/stages/compute-versions-stage.yml, resolving one SqlClient family version and one SqlServer version up front.build-stages.yml,publish-symbols-stage.yml, and the build/pack/publish jobs and steps consumesqlClient{Package,File}Versionfor all family packages andsqlServer*for SqlServer.release-stages.ymlcollapses the five family release toggles to onereleaseSqlClient(keptreleaseSqlServerServerseparate);package-variables.ymldrops hardcoded version values. (13 files)5. Document unified SqlClient family versioning
Adds
.github/instructions/sqlclient-package-versions.instructions.mddescribing family/SqlServer version resolution across all scenarios, renamespackage-versions.instructions.md→3rd-party-package-versions.instructions.md(now scoped to external deps), refreshes the OneBranch pipeline design notes, and updatesBUILDGUIDE.mdpack/build parameter tables and package-mode examples for the single family parameter. (4 files)6. Address reviewer feedback
Applies reviewer-requested corrections across canonical version imports,
build.proj, OneBranch version computation and argument flow, and the stress runner. It also replaces the compute-stage Bash with cross-platform PowerShell and tightens explicit package/file-version handling. (11 files)7. Remove unused OneBranch
isPreviewparameterRemoves the dead
isPreviewparameter and forwarding from both OneBranch entry pipelines andpackage-variables.yml; canonicalVersions.propsvalues now determine preview or stable package versions directly. (3 files)8. Add optional OneBranch package version revisions
Adds the opt-in
addRevisionparameter to official and non-official OneBranch pipelines. Pipeline runs use$(Rev:r)and can append the mapped run revision to packages built by that run, preserving prerelease suffixes, wrapping above the 65535 file-version limit with an Azure DevOps warning, and leaving an unbuilt published SqlServer dependency unchanged. Version computation is extracted into a documented, tested PowerShell script. (9 files)Version source of truth
After this PR, versions are computed in just two files:
src/Microsoft.Data.SqlClient/Versions.propsSqlClientPackageVersion,SqlClientFileVersion,SqlClientAssemblyVersion— shared by the whole familysrc/Microsoft.SqlServer.Server/Versions.propsSqlServerPackageVersion,SqlServerFileVersion,SqlServerAssemblyVersionEach
Versions.propsuses a 3-tier priority to resolve the version:*PackageVersionparameter - supersedes all (legacy PR/CI and OneBranch use this approach).BuildNumber(+ optionalBuildSuffix) → prerelease tag;BuildNumberis theFileVersionrevision component (modern PR/CI use this approach)-devsuffix for local developer builds.AssemblyVersionis always derived asMajor.0.0.0for strong-name backward compatibility.Resulting version differentiation
-dev7.1.0-preview3-dev-pr7.1.0-preview3-pr20250602.1-ci7.1.0-preview3-ci20250602.17.1.0-preview3Verification
dotnet buildstill produces-devversions:-prsuffixed versions:-prsuffixed versions:-cisuffixed versions:Package validation results
Every produced package was verified with the
PackageValidatortool (package, file, and assembly versions; symbol packages; and — for the official run — theMicrosoft.SqlServer.Serverdependency range). All runs passed with no unexpected-version findings.Microsoft.SqlServer.Server1.1.0-preview1[1.0.0, 2.0.0)-pr194021.1.0-preview1-pr19402-pr194021.1.0-preview1-pr19402-pr194021.1.0-preview1-pr19402-ci194091.1.0-preview1-ci19409-ci194031.1.0-preview1-ci19403Confirmed for every run:
Microsoft.Data.SqlClient,Internal.Logging,Extensions.Abstractions,Extensions.Azure, and the AKV Provider) — all 5 packages and every per-target-framework assembly — carry an identical package version, file version (7.1.0.<build>), and assembly version (7.0.0.0).Microsoft.SqlServer.Serveris versioned independently (1.1.0-preview1/ assembly1.0.0.0).AssemblyVersionis alwaysMajor.0.0.0for strong-name backward compatibility.-dev/-pr/-ci/ none).1.0.0; non-official builds SqlServer, giving nightly coverage of that flow.Future work
Deferred follow-ups, to be tracked/implemented separately:
build.projalready exposes the neededGetVersions*targets andPackageVersionSqlClient/PackageVersionSqlServerarguments, so this is pipeline-only work.)PackageVersionXYZnaming convention for version properties across pipelines,build.proj, and C# projects/props files.