feat(backports): list commits on main that have not reached a release branch

[aclark4life]

Summary

Assembling the next Backports for 5.2.5 LTS PR — successor to INTPYTHON-528 Backports for 5.2.4 LTS (#607) — means finding commits on django-mongodb-backend's main that aren't yet on 5.2.x. Nothing in dbx answered that.

The release-gap report from #71/#73 looks like it should, but it compares the Django fork against a released backend tag and never opens the backend's own branches. Wrong repos, wrong pair.

$ dbx backports django-mongodb-backend

📋 Backport candidates from upstream/main:

🌿 6.0.x
   since 6.0.4 (2026-07-14)
   ✅ nothing to backport (7 release chore(s) skipped)
🌿 5.2.x
   since 5.2.4 (2026-08-24)
   ✅ nothing to backport (1 release chore(s) skipped)
🌿 5.1.x
   ⚠️  No 5.1.* release tag — skipping (pass --since or --all to list anyway)

The window is the design

Candidates are bounded by the target branch's latest release tag, not the branch point:

bound	commits missing from 5.2.x
since the branch point	164 (82 after filtering chores)
since the 5.2.4 tag	1

The 164 are nearly all feature work the supported-versions policy forbids on LTS. They're also not candidates: each was already triaged when #607 was assembled, and either taken or deliberately skipped.

The window is load-bearing for correctness, not just brevity. Backports get squashed into one commit, so the main commits they carried keep their own patch-ids — git log --cherry-mark recognises only 6 of 164 as already present. Bounding by the tag sidesteps that, since everything the squash carried predates the tag.

The cost: a fix that should have been backported before the last release and was missed won't appear. --since and --all widen the window for that hunt. This is called out in the docs as a warning rather than left implicit.

Eligibility is left to the reader

Only security fixes and data-loss bugs belong on LTS branches per the backend's release-process.rst, and no commit subject marks those. The documented signal is the PR description — but ~4 of the last 60 merged PRs follow that convention and there's no backport label, so keying off it would report an empty list and look authoritative.

Release chores are filtered (version bumps including ticket-prefixed INTPYTHON-1050 Bump version to 6.1.0, dependency/actions bumps, SBOM, stub notes, release prep, CODEOWNERS, and Update to Django X.Y — the opposite of a backport). Everything else is shown.

Notes

• Branches with no release tag (5.1.x, 5.0.x) are skipped rather than falling back to the branch point, which dumped 262 and 290 lines in the first draft.
• Fetches by default: a stale clone under-reports, which is the dangerous direction. --no-fetch opts out.
• latest_release_tag / classify_commit / git_out move to utils/release.py so the two commands share them rather than importing across command modules. sync.py is refactor-only and its 30 tests are untouched.

Testing

• 13-case parametrized chore-filter test and 9 command tests (tag window, chore hiding, --all, = cherry-mark skipping, missing tag, --since override, unknown --to branch, branch ordering).
• Full suite: 511 passed. Docs build at the same 2 pre-existing warnings.