Summary

We are proposing that all SqlClient family of packages produced from this repository share a single Major.Minor.Patch version. This alignment would take effect at 7.0.2.

The Microsoft.SqlServer.Server package will keep its existing versioning scheme.

Current State

Today each package is versioned independently, for example:

While SqlClient and the AKV provider already share a major.minor, the remaining packages are at 1.x with no inherent compatibility signal tying them together.

Proposed Model

Starting at 7.0.2, all packages would share the same Major.Minor.Patch.

For example:

• SqlClient ships a hotfix → 7.0.2
• All other packages are bumped as well → 7.0.2

At the next feature release, all packages move to 8.0.0 together.

A breaking change in any package triggers the next major for all packages.

Motivation

1. Compatibility signal — Consumers immediately know that any 7.0.3 of any package is compatible with any other 7.0.2. No compatibility matrix needed.
2. Simplified release trains — A minor release is one logical event with unified release notes, announcements, and migration guides. "Upgrade to 8.0" is a single actionable statement.
3. Precedent — This is the established pattern for .NET BCL packages (e.g., Microsoft.Extensions.* all share major.minor and ship together at each wave).

What Changes

• A single shared Major.Minor.Patch property would be defined in a common props file.
• Each package's Versions.props derives its version from the shared property plus its own patch counter.
• All packages ship together at each patch release, even if a specific package has no changes in that cycle.
• The 1.x packages (Abstractions, Azure, Logging, SqlServer.Server):
  • Jump to package version 7.0.2.
  • Jump to Assembly Version 7.0.0.0
    • This communicates "new versioning policy starts here" and will require apps to re-build. Dropping a subset of the 7.0.2 DLLs into an existing app will not work on .NET Framework due to the binding identity change.

SNI Packages

The native SNI packages (Microsoft.Data.SqlClient.SNI and Microsoft.Data.SqlClient.SNI.runtime) are worth discussing separately:

Arguments for including SNI in the band:

• Simplifies the "what versions work together" story for the entire stack
• Consumers already expect SNI and SqlClient to be paired; shared versioning makes this explicit
• Reduces one more compatibility question

Arguments for keeping SNI independent:

• SNI follows the native binary's build/release lifecycle, which may not align with managed code releases
• SNI is Windows-only and ships from a separate build pipeline with different constraints
• SNI version bumps are driven by native code changes (OpenSSL updates, Windows API changes) that have no relation to the managed driver's feature cadence
• A forced major bump in SNI (due to a breaking change elsewhere) could confuse consumers about native compatibility

Our inclination: Include SNI in the band, which keeps versions consistent and compatiblity obvious.

Impact on Consumers

• Upgrading: "Upgrade to 7.0.2" covers the whole stack.
• Dependency resolution: Packages in the same band are always safe to use together.
• Servicing: All packages are released together with the same version.
• Breaking changes: Rare, but when they happen, the major bump across all packages makes it unambiguous that a new compatibility era has started.

Feedback Welcome

We'd like community input on this change before proceeding. Please share your thoughts, concerns, or questions below.