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 # check-new-releases
Checks Microsoft's public Windows 11 download page for a new "flagship" product Two complementary tools for finding Windows product edition IDs that exist on
edition ID not yet in `cli/catalog.go`, and if found, probes nearby IDs to Microsoft's side but aren't yet in `cli/catalog.go` / `products.json` /
discover the accompanying variant family (Home China, Pro China, ARM64, ...). `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 Only Windows 11 is worth checking at all: Windows 8.1 is fully frozen (no
is past end-of-life, so neither will ever produce a new consumer ISO release. updates since Jan 2023) and Windows 10 is past end-of-life (ESU security
Windows 11 is the only OS still shipping feature updates. 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`, ## Method 1 -- `msdls_v3.py` (brute-force range scan)
`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 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 ```bash
cd scripts/check-new-releases cd scripts/check-new-releases
@ -27,9 +71,21 @@ Flags:
- `-catalog <path>` — path to `cli/catalog.go` (default: `../../cli/catalog.go`) - `-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) - `-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 ## Which one to use
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 | | Method 1 (Python) | Method 2 (Go) |
wider `-probe-range`. |---|---|---|
| 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.