Moves msdls_v3.py from repo root into scripts/check-new-releases/, alongside a new Go tool, documented as Method 1 (Python brute-force range scan, can write results to a catalog-shaped JSON) and Method 2 (Go auto-discovery via page-scrape + bounded adjacent-ID probe, no range-guessing needed). Only Windows 11 is checked -- 8.1 is fully frozen and Windows 10 is past end-of-life, so neither will produce a new consumer ISO again. Fixed msdls_v3.py's release-name extraction: it checked EditionName/ ReleaseName/FriendlyName, none of which exist in the real API response -- the actual field is ProductDisplayName, confirmed live. Also added the vlscppe session-permit call to setup_session(), which was skipped entirely; higher-risk gap for this script's brute-force range-scan usage pattern than for a single lookup. Both tools' live runs surfaced a real catalog gap: product IDs 3322/3323/3325/3326 (Home/Pro China variants of the 25H2 "V2" refresh) exist on Microsoft's side but weren't in our catalog. Added them to cli/catalog.go, products.json, validContributeProducts, and sitemap.xml, and renamed 3321/3324 from our own guessed "(Updated Oct)" label to Microsoft's actual name for this refresh, "(V2)" (their internal name is "Windows 11 25H2__V2"; cleaned up the double-underscore for user-facing display). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| go.mod | ||
| main.go | ||
| msdls_v3.py | ||
| README.md | ||
check-new-releases
Checks Microsoft's public Windows 11 download page for a new "flagship" product
edition ID not yet in cli/catalog.go, and if found, probes nearby IDs to
discover the accompanying variant family (Home China, Pro China, ARM64, ...).
Windows 8.1 and Windows 10 aren't checked -- 8.1 is fully frozen and Windows 10 is past end-of-life, so neither will ever produce a new consumer ISO release. Windows 11 is the only OS still shipping feature updates.
This tool only discovers candidate IDs. It doesn't touch cli/catalog.go,
products.json, or validContributeProducts automatically -- naming a new
entry correctly (build number, "Updated Oct"-style qualifiers, etc.) needs a
human checking Microsoft's own release-health pages.
Usage
cd scripts/check-new-releases
go run .
If a new release is found, it makes real requests to Microsoft to probe the variant family -- let it finish rather than re-running immediately.
Flags:
-catalog <path>— path tocli/catalog.go(default:../../cli/catalog.go)-probe-range <n>— how many adjacent IDs to check after a new flagship is found (default: 20)
Known limitation
The ARM64 family's offset from the flagship isn't consistent release to
release (observed: +3 for the 25H2 family, +18 for 24H2's). The default probe
range of 20 covers both known cases, but if no ARM64 variant shows up, try a
wider -probe-range.