0.8.0 rehearsal (2026-10-29)

After the stamp pull request merged as d7adb9ae, the pair was rehearsed on that commit with one annotated prerelease tag each (annotations carry the rehearsal notes; a tag is never moved). The 0.7.0 rehearsal above is the template, including its lesson: a failed rehearsal gets the next -rc.N on the commit that carries the fix.

git tag -a python-v0.8.0-rc.1 d7adb9ae -m "qgis-sdk 0.8.0-rc.1 (rehearsal) ..."
git tag -a ts-v0.6.0-rc.1 d7adb9ae -m "@archont561/qgis-sdk 0.6.0-rc.1 (rehearsal) ..."
git push origin python-v0.8.0-rc.1 ts-v0.6.0-rc.1

Tag	release.yml run	Outcome
python-v0.8.0-rc.1	40972199140	every job green: build stamped 0.8.0-rc.1 for scope python, “Verify the stamped manifests and the shared contract” passed (the example-window defect class python-v0.7.0-rc.1 hit does not recur), the support matrix was recorded, three wheels built and twine-checked, three Conda outputs built; pypi ran “Verify the wheel without uploading” with all three publish steps skipped; conda skipped the prefix.dev upload; github-release published the prerelease with the three wheels, the three .conda files and SHA256SUMS
ts-v0.6.0-rc.1	40972199246	every job green: build stamped 0.6.0-rc.1 and built the bridge; npm packed the bridge and alias tarballs, smoke-tested the alias against the bridge tarball and ran its publish dry-run with both publish steps skipped; github-packages ran its dry-run; github-release published the prerelease with archont561-qgis-sdk-0.6.0-rc.1.tgz, qgis-sdk-0.6.0-rc.1.tgz and SHA256SUMS

Nothing was published to a registry, which is the point of the rehearsal: PyPI still serves qgis-sdk up to 0.7.0 and npm still serves @archont561/qgis-sdk’s latest at 0.5.0, with neither 0.8.0 nor 0.6.0 listed. Both trains of the pair are proven end to end.

The real pair was cut on the same commit d7adb9ae once the owner said “publish”; ui-v0.1.0 was not re-tagged, because the ui scope is skipped for this train and its 0.1.0 stays the release it was. See Released afterwards below.

Released afterwards (2026-10-29)

python-v0.8.0 and ts-v0.6.0 are annotated tags on d7adb9ae, the stamp pull request’s merge commit, and ran release.yml twice:

• python-v0.8.0, run 40975585654: build, pypi, conda and github-release succeeded; the npm and ui jobs skipped. Every publish step ran for real - “Publish qgis-sdk-runtime / qgis-sdk-tools / qgis-sdk to PyPI” and the three prefix.dev uploads - with the prerelease skip step itself skipped, as it must be for a stable tag.
• ts-v0.6.0, run 40975585334: build, npm, github-packages and github-release succeeded; everything else skipped, with “Publish to npm”, “Publish the alias to npm” and “Publish to GitHub Packages” all real.

PyPI serves qgis-sdk, qgis-sdk-runtime and qgis-sdk-tools 0.8.0 as latest, one wheel each, requires-python >=3.11, with the same digests built here on the stamped tree: qgis_sdk-0.8.0 0b390cf8…, qgis_sdk_runtime-0.8.0 f7828256…, qgis_sdk_tools-0.8.0 b61c3d33…

• the build is reproducible. Installing the published qgis-sdk[mcp]==0.8.0 into a fresh CPython 3.11.2 venv resolves mcp 2.3.0 and mcp-types 2.3.0 with no “does not provide the extra” warning, pip check is clean, and qgis-sdk mcp --help renders. That venv’s qgis-sdk new --ui native --web vanilla writes qgis-sdk-runtime>=0.8,<0.9 and "@archont561/qgis-sdk": "0.6.0", and check is clean on it; targets still prints the four-row matrix, naming the Windows and macOS QGIS rows unqualified.

npm serves @archont561/qgis-sdk and its alias qgis-sdk at 0.6.0 as latest, 7 exports each, with no dependency on a peer gone wrong. The release assets are the three wheels, the three .conda files (qgis-sdk-0.8.0-pyh0f40b72_0, qgis-sdk-runtime-0.8.0-pyh4616a5c_0, qgis-sdk-tools-0.8.0-pyh4616a5c_0) and SHA256SUMS for python-v0.8.0, and both tarballs plus SHA256SUMS for ts-v0.6.0; both releases are published, neither is a prerelease.

Not verifiable from the sandbox: the prefix.dev channel and the release-asset CDN, which are attested by the run logs only; Conda reproducibility, since build:conda cannot fetch conda-forge here. The ui packages stay at 0.1.0 and the owner’s earlier note about their 0.0.0 placeholders still stands.

Run the webengine harnesses in separate processes. The scaffold-web harness drives a generated plugin’s view, which uses Chromium’s default profile, while test_webchannel_native.py and test_webengine_native.py share the session’s off-the-record webengine_profile. One process that runs the former and then either of the latter aborts (exit 134, after every test passed) when Chromium tears the profiles down. Since 2026-10-25 tests/conftest.py skips the other webengine modules, with the reason, whenever test_scaffold_web_native.py is collected in the same process (QGIS_SDK_SCAFFOLD_WEB=1), so a combined invocation reports skips instead of dying; the evidence run stays one file per process.