Summary

We are proposing that all packages produced from this repository share a single Major.Minor version, with each package retaining an independent Patch version for servicing releases. This alignment would take effect at 8.0.0.

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 8.0.0, all packages would share the same Major.Minor. Each package independently increments its patch version when servicing is needed.

For example, after the initial 8.0.0 release:

• SqlClient ships a fix → 8.0.1
• All other packages remain at 8.0.0
• Logging needs a fix later → 8.0.1 (its own independent patch)

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

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

Motivation

1. Compatibility signal — Consumers immediately know that any 8.0.x of any package is compatible with any other 8.0.x. 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 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 minor release, even if a specific package has no changes in that cycle.
• Patch releases remain independent — only the affected package ships.
• The 1.x packages (Abstractions, Azure, Logging, SqlServer.Server) jump to 8.0.0. This communicates "new versioning policy starts here."

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 8.0" covers the whole stack.
• Dependency resolution: Packages in the same band are always safe to use together.
• Servicing: Only the patched package needs updating; other packages at the same major.minor are unaffected.
• 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.