shekhar/windows-iso-downloader
1
0
Fork 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions

docs: finish check-new-releases README rewrite

Browse source 
Prior commit staged an intermediate version of this file. Completes
the Method 1 / Method 2 writeup with usage examples, the comparison
table, and the field-name bug/session-permit history.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Shekhar Vaidya 2026-07-14 11:10:11 +05:30
parent da8787e93a
commit c30c2d2b3b
1 changed files with 72 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

88
scripts/check-new-releases/README.md
View file

@ -1,19 +1,63 @@
# 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, ...).
Two complementary tools for finding Windows product edition IDs that exist on
Microsoft's side but aren't yet in `cli/catalog.go` / `products.json` /
`validContributeProducts`. Neither touches those files automatically --
naming a new entry correctly (build number, refresh qualifiers like "V2",
etc.) still needs a human checking Microsoft's own release-health pages.
Both only *discover* candidates.
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.
Only Windows 11 is worth checking at all: Windows 8.1 is fully frozen (no
updates since Jan 2023) and Windows 10 is past end-of-life (ESU security
patches only, delivered via Windows Update, not new consumer ISOs). Neither
will ever produce a new release again.
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.
## Method 1 -- `msdls_v3.py` (brute-force range scan)
## Usage
Checks every ID in a range you specify, one by one, against Microsoft's
SKU-info API. Use this when you already have a rough idea of where to look
(e.g. "the last release was around 3260, check up to 3350") or want to
directly merge results into a JSON catalog file.
```bash
pip install requests
python msdls_v3.py --first 3320 --last 3330
```
Optionally write results to a JSON file (merges with an existing one if
present, preserving fields like `badge`/`archs`/`related`, marking IDs that
stopped responding as `"active": false`):
```bash
python msdls_v3.py --first 3320 --last 3330 --write scan-results.json
```
Don't point `--write` directly at `frontend/public/data/products.json` --
write to a scratch file first and review before merging into the real
catalog.
**How it identifies a release:** reads `ProductDisplayName` from the first
SKU in the API response (e.g. `"Windows 11 25H2__V2"`). This field name was
wrong in an earlier version of this script (checked `EditionName`/
`ReleaseName`/`FriendlyName`, none of which exist in the real response) --
confirmed live and fixed 2026-07-14.
**Session handling:** registers the session via `vlscppe`'s permit endpoint
before scanning. A single SKU lookup was confirmed to work without this, but
this script's use case -- many rapid consecutive requests across a range --
is a much higher-risk pattern for triggering a Sentinel block than a
one-shot lookup, so the permit call is worth keeping. The CLI/backend's full
session flow additionally replays an `ov-df.microsoft.com` fingerprint; add
that too if the permit call alone isn't enough under real scanning load.
## Method 2 -- `main.go` (auto-discovery)
Scrapes Microsoft's public `/windows11` download page for the *current*
flagship product edition ID (no range-guessing needed), compares it against
`cli/catalog.go`, and if it's new, probes a bounded range of adjacent IDs to
discover the accompanying variant family (Home China, Pro China, ARM64).
Use this when you just want to know "is there anything new" without knowing
where to look.
```bash
cd scripts/check-new-releases
@ -27,9 +71,21 @@ Flags:
- `-catalog <path>` — path to `cli/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
**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`.
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`.
## Which one to use
| | Method 1 (Python) | Method 2 (Go) |
|---|---|---|
| Need to guess a starting range? | Yes | No -- finds the current flagship automatically |
| Gets the real Microsoft name? | Yes (`ProductDisplayName`) | Yes (`ProductDisplayName`) |
| Can write results to a catalog-shaped JSON? | Yes (`--write`) | No -- prints a report only |
| Best for | "I want to scan a specific range and get a mergeable file" | "Just tell me if anything's new" |
Both were verified end-to-end against live Microsoft endpoints on
2026-07-14, which surfaced a real gap: product IDs `3322`/`3323`/`3325`/`3326`
(Home/Pro China variants of the 25H2 "V2" refresh) existed on Microsoft's
side but weren't yet in the catalog. Since fixed.