Release readiness: derive version and beta/stable from package version, not the Planned Releases label (Patch rows fail)

[helen229]

Summary

The SDK release-readiness gate decides "planned release date" and "preview vs. stable" from the Planned Releases field on the ADO Package work item. That field is parsed by a regex that only recognizes Beta | Stable | GA release-type labels, so any other label (notably Patch) fails to parse. When that happens the tool reports "No planned release date found for current package version X" even though a valid planned row with a date exists, and it blocks the release.

Requested change: use the package version (not the Planned Releases label) to determine the version and whether the release is beta or stable, and only use Planned Releases to look up the release date (if a planned date is required at all).

Symptom

A service team hit No planned release date found for current package version 1.2.1 when releasing JS (@azure/arm-computelimit) and Go (armcomputelimit) from Release Plan 35165. On the tool's recommendation they created a "missing planned release date" work item, but the date was actually already set.

Digging in:

• JS (WI 35021) and Go (WI 35022) both have a planned row Patch | 1.2.1 | 2026-07-07, ChangeLogStatus = Success. The date is present.
• .NET (WI 35073) and Java (WI 35061) have GA | 1.3.0 | 2026-07-07 and released fine.
• Python 1.2.1 in the same plan is also a Patch and shipped fine — the pipeline itself handles patches; only this readiness gate rejects them.

So it's the release-type label (GA vs Patch), not the version number, that decides pass/fail today.

Root cause

SdkReleaseDetailsRegex in DevOpsService.cs only matches Beta|Stable|GA:

// tools/azsdk-cli/Azure.Sdk.Tools.Cli/Services/DevOpsService.cs:157
[GeneratedRegex("\\|\\s(Beta|Stable|GA)\\s\\|\\s([\\S]+)\\s\\|\\s([\\S]+)\\s\\|")]
private static partial Regex SdkReleaseDetailsRegex();

A Patch row doesn't match, so ParseHtmlPackageData returns zero entries for that package. Then in the readiness check:

// tools/azsdk-cli/Azure.Sdk.Tools.Cli/Tools/Package/SdkReleaseTool.cs:251
var plannedRelease = package.PlannedReleases.FirstOrDefault(r => r.Version.Equals(package.Version)) ?? package.PlannedReleases.LastOrDefault();
package.PlannedReleaseDate = plannedRelease?.ReleaseDate ?? "Unknown";
if (package.PlannedReleaseDate.Equals("Unknown"))
{
    package.IsPackageReady = false;
    package.PackageReadinessDetails = $"No planned release date found in package details for current package version {package.Version}. ...";
}

var releaseType = plannedRelease?.ReleaseType ?? "Unknown";
bool isPreviewRelease = releaseType.Equals("Beta");

• No parsed entry → PlannedReleaseDate = "Unknown" → IsPackageReady = false → the misleading error.
• The preview/stable decision (isPreviewRelease) is also driven off the Planned Releases label, which then gates namespace approval and APIView checks.

Proposed fix

1. Use the package version to find the version and to decide beta vs. stable. Determine preview/stable from the package version string (a prerelease/-beta suffix ⇒ preview, otherwise stable) instead of the Planned Releases release-type label.
2. Use that version to look up the release date in Planned Releases only if a planned release date is actually required — rather than relying on the label to both identify the row and classify the release.

This decouples readiness from the specific label emitted into Planned Releases and fixes Patch (and any future release-type labels) without a fragile regex allowlist.

Notes / related

• The upstream emitter does write Patch as a legitimate planned release-type label, so the gate should tolerate it.
• Possibly the same failure mode as a separately reported release issue for @azure/arm-storage (JS mgmt) — worth cross-checking once fixed.
• Priority: medium. A second customer has now hit the same gate, so it is recurring.

References

• tools/azsdk-cli/Azure.Sdk.Tools.Cli/Services/DevOpsService.cs:157 (regex allowlist)
• tools/azsdk-cli/Azure.Sdk.Tools.Cli/Tools/Package/SdkReleaseTool.cs:251-260 (readiness + preview/stable decision)