Add ReleaseDate for SQL Server 2017, 2019, 2022 and 2025 releases to dbatools-buildref-index.json / Show ReleaseDate in Get-DbaBuild and Test-DbaBuild / Add -MaxTimeBehind to Test-DbaBuild

[andreasjordan]

Adds ReleaseDate field to RTM and all named CU entries for SQL Server 2022 (v16, RTM+CU1–CU24) and SQL Server 2025 (v17, CU1–CU3).

Dates sourced directly from official Microsoft documentation:

• https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2022/build-versions
• https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2025/build-versions

This enables time-based compliance checking as described in issue #9259, where organizations want to verify instances are within a time window (e.g., 6 months) rather than a fixed number of CUs behind.

Closes #9259

Generated with Claude Code

[andreasjordan]

If it is that ease to add the dates based on the official sources, then we should to that. And we should let Claude check the current contents of the json to be sure it is correct.

We should add the non-CU dates as well (add all we can get) and continue with all the currently supported versions.

[potatoqualitee]

will merge with @niphlod 's approval

[andreasjordan]

After @niphlod 's approval we should add the ReleaseDate to all patches (not just CUs) of all currently supported versions. I just did not want to burn tokens for that if we don't agree on this way.

[niphlod]

in general, I agree (even if personally I don't find it useful). As long as everybody agrees that support for "let's install this given x months passed" will be ONLY based on "rightfully confirmed and present "ReleaseDate" attribute".
Also, how is it gonna be intertwined with "let's install this IF IT'S a CU and x months passed" ?

[andreasjordan]

@claude please add the release date for all patches listed on those pages:

• https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2025/build-versions
• https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2022/build-versions
• https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2019/build-versions
• https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2017/build-versions

[claude]

Claude finished @andreasjordan's task in 13m 47s —— View job

---

Adding Release Dates for SQL Server Patches

• Gather context and understand request
• Fetch release dates from Microsoft docs for SQL Server 2025
• Fetch release dates from Microsoft docs for SQL Server 2022
• Fetch release dates from Microsoft docs for SQL Server 2019
• Fetch release dates from Microsoft docs for SQL Server 2017
• Read current JSON file
• Update JSON with all release dates
• Commit and push changes

Summary

Added ReleaseDate to all patches listed on the four Microsoft documentation pages:

Version	RTM	GDR	CU+GDR	CU (new)	Already had date
SQL Server 2017 (14.x)	✅	16 entries	20 entries	31 CUs	—
SQL Server 2019 (15.x)	✅	17 entries	14 entries	32 CUs	—
SQL Server 2022 (16.x)	—	14 entries	13 entries	—	24 CUs + RTM
SQL Server 2025 (17.x)	—	2 entries	1 entry	—	3 CUs

Total: 185 ReleaseDate entries in the file after this commit (up from 28).

Notes:

• Two SQL Server 2017 entries (14.0.3164 / KB4506633 and 14.0.3208 / KB4510083) were not found on the Microsoft docs pages so no date was added for them.
• One SQL Server 2019 entry (15.0.2090 / KB5010657) was also not on the referenced pages so no date was added.
• SQL Server 2025 RTM date is not listed on the Microsoft docs page, so no date was added.
  |

[andreasjordan]

If anyone wants to check:

$buildref = Get-Content -Path .\bin\dbatools-buildref-index.json | ConvertFrom-Json
$properties = $buildref.Data.ForEach({$_.PSObject.Properties.Name}) | Select-Object -Unique
$buildref.Data.Where({$_.Version -match '^17'}) | Format-Table -Property $properties
$buildref.Data.Where({$_.Version -match '^16'}) | Format-Table -Property $properties
$buildref.Data.Where({$_.Version -match '^15'}) | Format-Table -Property $properties
$buildref.Data.Where({$_.Version -match '^14'}) | Format-Table -Property $properties

[andreasjordan]

About the missing dates:

I found those on https://sqlserverbuilds.blogspot.com/

14.0.3164 / KB4506633: 2019-06-20
https://support.microsoft.com/en-us/topic/kb4506633-on-demand-hotfix-update-package-for-sql-server-2017-cu15-4fed58e0-ba42-b247-89db-9d93929d72d7

14.0.3208 / KB4510083: 2019-07-09
https://support.microsoft.com/en-us/topic/kb4510083-on-demand-hotfix-update-package-2-for-sql-server-2017-cu15-5a04ceb8-b93d-43d7-c767-e96e307744e4

15.0.2090 / KB5010657: 2022-02-08
https://support.microsoft.com/en-us/topic/kb5010657-description-of-the-security-update-for-sql-server-2019-gdr-february-8-2022-49c03140-0495-4504-82cd-e920c2ea81bc

SQL Server 2025 RTM: 2025-11-18

I will add them now...

[andreasjordan]

@claude are you able to read #9259 (comment) and implement the changes to Test-DbaBuild?

[claude]

Claude finished @andreasjordan's task in 4m 55s —— View job

---

Implementing Changes to Test-DbaBuild

• Gather context and understand request
• Attempt to read issue Add option to use a time-period when using Test-DbaBuild #9259 comment — ⚠️ see note below
• Read current Test-DbaBuild implementation
• Implement the requested changes
• Update tests if needed
• Commit and push changes

⚠️ Cannot Access the Issue Comment

I'm unable to read the specific comment at #issuecomment-3589932966 because the gh CLI and web fetch tools require additional permissions that aren't granted in this run.

To unblock me, you can either:

1. Grant tool permissions — add gh or Bash with network access to the allowed tools in the workflow, or
2. Paste the comment content here and tag me again with @claude, and I'll implement the changes immediately.

I've already read the current Test-DbaBuild.ps1 implementation and understand its structure. Once I can see the specification, I can implement the time-based compliance feature using the ReleaseDate fields that were just added to the build reference JSON.

[andreasjordan]

@claude - Here is the content of that comment:

---

Analyzing time-based compliance checking for Test-DbaBuild

Tasks

• Read Test-DbaBuild command implementation
• Read dbatools-buildref-index.json structure
• Analyze feasibility and provide recommendations
• Provide detailed analysis to @potatoqualitee

---

My Assessment

I think this is a reasonable and practical feature request that addresses a real-world compliance need. Here's my analysis:

Why This Makes Sense

1. Different CU cadences: As the issue author correctly notes, "2 CUs behind" can mean 2 months for one SQL Server version but 12+ months for another. Time-based compliance is more consistent across versions.

2. Alignment with security policies: Many organizations have security policies like "all systems must be patched within 6 months" rather than "must be within X CUs behind." This feature would align dbatools with how compliance is actually measured.

3. Predictable maintenance windows: Organizations plan patching on time schedules (quarterly, semi-annually), not on "wait for N CUs to release" schedules.

4. Existing pattern: The command already has MaxBehind for CU-based checks. Adding MaxTimeBehind would be a natural extension of this pattern.

Implementation Approach

The implementation is straightforward and follows existing dbatools patterns:

1. Add ReleaseDate field to JSON (lines like 4875-4925 in /home/runner/work/dbatools/dbatools/bin/dbatools-buildref-index.json:4875)

{
    "CU": "CU10",
    "Version": "16.0.4095",
    "KBList": "5031778",
    "ReleaseDate": "2023-11-16T00:00:00"
}

2. Add MaxTimeBehind parameter to Test-DbaBuild

• Similar to MaxBehind (line 121 in /home/runner/work/dbatools/dbatools/public/Test-DbaBuild.ps1:121)
• Parse formats like "6Mo", "3M", "180D" (months or days)
• Make it mutually exclusive with MinimumBuild, MaxBehind, and Latest

3. Add time-based compliance logic

• Calculate days since the current build's release date
• Compare against threshold
• Return compliance status

4. Pragmatic data strategy

• Start by adding dates for SQL Server 2016+ CUs only (versions 13-17)
• Older versions (SQL 2000-2014) can be added incrementally if needed
• Missing dates would result in "Cannot determine compliance - release date not available" message

Addressing Previous Concerns

Regarding @niphlod's concerns:

• "Too much hassle to set up": We can start with just recent versions (2016+). Release dates are publicly available from Microsoft's KB articles.
• "Bad compliance posture": I respectfully disagree - time-based patching IS a valid compliance model used by many organizations (e.g., "patch within 6 months of release")
• "MS cadence is predictable": It's predictable but not identical across versions, which is exactly why time-based checking is useful

Example Usage

# Check if instances are within 6 months of latest CU
Test-DbaBuild -SqlInstance $servers -MaxTimeBehind 6Mo

# Check if instance is within 180 days
Test-DbaBuild -SqlInstance prod-sql01 -MaxTimeBehind 180D

# Update index and check compliance
Test-DbaBuild -SqlInstance $servers -MaxTimeBehind 6Mo -Update

Data Collection Strategy

I can help gather release dates from Microsoft KB articles. Each CU KB article contains the release date. For example:

• SQL 2022 CU10 (KB5031778) was released November 16, 2023
• SQL 2019 CU23 (KB5030333) was released October 12, 2023

This data is public and standardized across all KB articles.

---

Recommendation

I recommend implementing this feature with the following scope:

1. ✅ Add ReleaseDate field to JSON for SQL Server 2016+ CUs (versions 13-17)
2. ✅ Add MaxTimeBehind parameter with 6Mo, 3M, 180D format support
3. ✅ Add time-based compliance checking logic
4. ✅ Handle missing dates gracefully with clear messaging
5. ✅ Update tests to cover new parameter

This addresses real compliance needs without significant maintenance burden. The feature can be expanded to older versions later if there's demand.

@potatoqualitee - If you'd like me to proceed with the implementation, I'm ready to:

1. Research and add release dates for SQL 2016+ CUs
2. Implement the MaxTimeBehind parameter
3. Add appropriate tests
4. Create a PR

Let me know if you'd like me to move forward!

---

[andreasjordan]

@claude I just added the content of the comment in the comment obove.

[claude]

Claude finished @andreasjordan's task in 5m 26s —— View job

---

Implementing MaxTimeBehind Parameter for Test-DbaBuild

• Gather context and understand request
• Read current Test-DbaBuild implementation
• Understand existing MaxBehind logic
• Add MaxTimeBehind parameter (formats: 6Mo for months, 180D for days)
• Implement time-based compliance logic using ReleaseDate from JSON
• Handle missing dates gracefully
• Update tests
• Commit and push changes

Summary

Added -MaxTimeBehind to Test-DbaBuild following the same patterns as the existing -MaxBehind parameter.

How it works:

• Parses formats like 6Mo (months) or 180D (days)
• Looks up the current build's ReleaseDate in the index
• Compares that date against today - MaxTimeBehind (the cutoff date)
• If the build was released before the cutoff → non-compliant
• If no ReleaseDate is available for the build → warns and returns non-compliant
• Sets BuildTarget to the oldest build within the time window (minimum acceptable version)

Usage examples:

# Check if instances are running a build released within the last 6 months
Test-DbaBuild -SqlInstance $servers -MaxTimeBehind "6Mo"

# Check if a specific build is within 180 days
Test-DbaBuild -Build "16.0.4095" -MaxTimeBehind "180D"

# Update index first, then check
Test-DbaBuild -SqlInstance $servers -MaxTimeBehind "6Mo" -Update

Changes:

• public/Test-DbaBuild.ps1 — added parameter, parsing, compliance logic, updated output/hidden props and docs
• tests/Test-DbaBuild.Tests.ps1 — added MaxTimeBehind to parameter validation test + 3 unit tests for compliant/non-compliant/no-date cases
  |

[andreasjordan]

@claude please add [datetime]$currentBuildEntry.ReleaseDate to the output object of Test-DbaBuild.

[claude]

Claude finished @andreasjordan's task in 1m 5s —— View job

---

Adding ReleaseDate to Test-DbaBuild Output

• Gather context and understand request
• Read Test-DbaBuild.ps1 to find output object
• Add ReleaseDate property to output object
• Commit and push changes

Summary

Added ReleaseDate as a property on the output object of Test-DbaBuild. For each build version tested, the code now looks up the matching entry in $IdxRef and casts its ReleaseDate to [datetime] (or $null if not available). This works across all parameter modes (-MinimumBuild, -MaxBehind, -Latest, -MaxTimeBehind).

Changes in public/Test-DbaBuild.ps1:

• Added lookup of $buildRefEntry from $IdxRef at the start of each build's processing loop
• Added Add-Member ... -Name ReleaseDate -Value $releaseDate to the output object
  |

[andreasjordan]

@claude can we add ReleaseDate also to the output of Get-DbaBuild?

[claude]

Claude finished @andreasjordan's task in 1m 35s —— View job

---

Adding ReleaseDate to Get-DbaBuild Output

• Gather context and understand request
• Read Get-DbaBuild.ps1 implementation
• Add ReleaseDate to output object
• Commit and push changes

Summary

Added ReleaseDate as a property on the output object of Get-DbaBuild.

Changes in public/Get-DbaBuild.ps1:

• In Resolve-DbaBuild, added capture of ReleaseDate from the index entry (same pattern as SupportedUntil): $Detected.ReleaseDate = [datetime]$el.ReleaseDate
• Added ReleaseDate = $Detected.ReleaseDate to all four PSCustomObject output blocks (SqlInstance, Build, Kb, MajorVersion paths)
• Updated .OUTPUTS documentation to document the new property

Usage:

Get-DbaBuild -SqlInstance $servers | Select-Object Build, ReleaseDate
Get-DbaBuild -Build "16.0.4095" | Select-Object Build, ReleaseDate, SupportedUntil

ReleaseDate will be $null for builds that don't yet have a date in the index.