From b2c343394ba4e9b923965ae2c7153adfee4f5182 Mon Sep 17 00:00:00 2001 From: jnasbyupgrade Date: Tue, 11 Aug 2026 12:20:25 -0500 Subject: [PATCH] RELEASE.md: promote dependency-override check to a pre-release gate extension_tools#45 highlighted that this rule (never release while CI builds a dependency from a git ref instead of its published PGXN version) was only documented as a passive "notes/gotchas" aside, not an actual step in the pre-release checklist -- easy to skip since nothing forces you to read that far. Move the real explanation into step 2's checklist and leave a pointer behind in its place. --- RELEASE.md | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/RELEASE.md b/RELEASE.md index 82c9040..90377fb 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -97,6 +97,20 @@ still matches what that version actually shipped: trustworthy regardless of vendored version; when in doubt, also eyeball the raw `pg_regress` output rather than trusting a green checkmark alone. +- [ ] **No CI dependency-override toggle is currently set.** If this repo's + CI has a toggle to build a dependency from a git ref instead of its + published PGXN version (typically added because the published + version doesn't yet satisfy what this repo actually needs), it must + be unset before you proceed. Check the toggle's *live value in CI + config* (e.g. `ci.yml`'s `env:`), not just whether the Makefile + *supports* the override — a normally-empty, always-present opt-in + variable existing in the Makefile doesn't mean anything is currently + pinned. Releasing while it's set produces a real, publishable zip + that declares a dependency floor nothing on PGXN can actually + satisfy — anyone who installs it gets a build failure, not the + tested code. If it's set, stop: wait for the real dependency version + to land on PGXN and the override to be reverted before cutting this + release. ## 3. Decide the version and what to track @@ -236,12 +250,6 @@ repo that adopts it — not yet done anywhere in the org. - CI passing is **not** proof the test suite passed on every vendored pgxntool version — see step 2. This has bitten real PRs (every `pg_regress` test failing while CI reported success). -- If this repo's CI has a dependency override toggle (e.g. building a - dependency from a git ref instead of its published PGXN version because - the published version doesn't satisfy what this repo actually needs), - check it's unset before cutting a release — a release cut while it's set - produces a zip that declares a dependency floor nothing on PGXN can - actually satisfy. Check the toggle's live value in CI config, not just - whether the Makefile *supports* overriding it — a normally-empty, - always-present opt-in variable existing in the Makefile doesn't mean - anything is currently pinned. +- A CI dependency-override toggle (build a dependency from a git ref + instead of its published PGXN version) must be unset before cutting a + release — see step 2 above.