Version gating has no single source of truth - 166 comparisons across 78 files

[andreasjordan]

Summary

Version gating is spread across the module with no single source of truth. Each site carries a bare major version number, so adding a SQL Server release, or reacting to SMO dropping an old one, means finding every one of them by hand. Raised by @niphlod in #10597 (comment).

Scale

Measured on development:

• 166 VersionMajor -<op> <n> comparisons across 78 files.
• 149 Connect-DbaInstance -MinimumVersion <n> call sites: 88 pass 9, 36 pass 10, 20 pass 11, 4 pass 13, one passes 8, one passes 1.
• 30 further $server.Version comparisons, plus DatabaseEngineType (27) and DatabaseEngineEdition (16) checks that gate on the same kind of thing.

Nothing ties a number to the feature it stands for, so the intent has to be re-derived from context at every site.

Two things this already costs us

The numbers drift silently. public/Copy-DbaSsisCatalog.ps1:287 connects to the source with -MinimumVersion 11; line 316 connects to the destination with -MinimumVersion 1. The help for both parameters says SQL Server 2012 or higher. A dropped digit, invisible to review and to the test suite.

The guidance moved and the call sites did not. #10597 establishes that SMO's own enumerators require SQL Server 2008, so any command walking Databases, Logins or similar needs -MinimumVersion 10, not 9. That makes most of the 88 sites passing 9 nominally wrong. Correcting them one by one is exactly the work a central table would make unnecessary next time.

Shape of a fix

A table mapping feature to minimum version, and a private helper that commands ask by name rather than by number, so a new release or a changed floor is one edit:

if (Test-DbaFeatureSupport -SqlInstance $server -Feature QueryStore) { ... }

Connect-DbaInstance -MinimumVersion stays as it is. It is the connection-level contract - "do not hand me a server older than this" - and #10597 makes it enforceable on versions where SMO cannot report one. What moves out is per-feature branching that currently reuses it.

SMO's floor is machine readable

The concern that SMO will keep dropping old versions faster than we notice can be answered mechanically. Each enumerator definition in Microsoft.SqlServer.SqlEnum.dll declares its own floor:

$assembly = [Reflection.Assembly]::LoadFrom("$smoPath\Microsoft.SqlServer.SqlEnum.dll")
$stream = $assembly.GetManifestResourceStream("Database.xml")
(New-Object System.IO.StreamReader($stream)).ReadToEnd() -match "min_major='(\d+)'"

In the currently pinned build, Server.xml, Information.xml, Database.xml and Login.xml all declare 10, and 224 of the 298 definitions that declare a floor declare 10. A test reading this against the version pinned in .github/dbatools-library-version.json would fail when a library bump raises the floor, rather than leaving it to be discovered from a bug report.

Not proposed here

Fixing the Copy-DbaSsisCatalog typo, which is a one-line change and belongs in its own pull request.

This text was created by Claude and reviewed by Andreas Jordan.