From b9a135c718a4874fbbfe80289519f95ad4798224 Mon Sep 17 00:00:00 2001 From: jnasbyupgrade Date: Wed, 5 Aug 2026 18:11:49 -0500 Subject: [PATCH] Bump cat_tools floor to 0.3.0, wire CI to use the git-source override The version decision this repo actually needs, separated from PR #10's install-mechanism change. extension_drop.sql calls cat_tools.routine__parse_arg_types_text(), which only exists starting at cat_tools 0.3.0 -- PGXN's published listing is stuck at a stale 2017 0.2.1 lacking it. Bumping META's declared floor makes a plain `pgxn install extension_drop` fail cleanly at dependency-resolution time instead of installing successfully and breaking later at CREATE EXTENSION time. Sets CAT_TOOLS_GIT_REF=0.3.0 at ci.yml's workflow level (not per-job), so every job that builds the extension -- including ones in other stacked PRs that already read this value via `make print-CAT_TOOLS_GIT_REF` -- picks it up automatically. Updates RELEASE.md's release-blocking guardrail: the real signal is now whether ci.yml's CAT_TOOLS_GIT_REF is actually set to a non-empty value, not whether the Makefile merely declares the variable (it always does now, as a normally-empty opt-in override). --- .github/workflows/ci.yml | 10 ++++++++++ META.in.json | 4 ++-- META.json | 4 ++-- RELEASE.md | 24 +++++++++++++++++++++++- 4 files changed, 37 insertions(+), 5 deletions(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 25a27f1..01a290b 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -8,6 +8,16 @@ on: push: branches: [master] pull_request: +# CAT_TOOLS_GIT_REF is the Makefile's opt-in override (see its comment there) +# to install cat_tools from a git ref instead of PGXN, for exactly this CI -- +# PGXN's published cat_tools is stuck at a stale 2017 release missing the +# function extension_drop's SQL calls. Set at workflow level (not per-job) so +# every job that builds/installs the extension, including ones in other +# stacked PRs, picks it up automatically without its own copy of this value. +# Revert this once cat_tools 0.3.0 is actually published to PGXN -- see +# RELEASE.md's guardrail against cutting a release while this is still set. +env: + CAT_TOOLS_GIT_REF: 0.3.0 jobs: # Style linter (https://github.com/Postgres-Extensions/linter, vendored at # .vendor/linter). Deliberately checked out WITHOUT submodules -- `make diff --git a/META.in.json b/META.in.json index 71aa541..d7c8cdb 100644 --- a/META.in.json +++ b/META.in.json @@ -73,13 +73,13 @@ "X_comment": "Valid keys for 'prereqs' are configure, build, runtime, or test.", "X_comment": "Valid keys for 'requires' are requires, recommends, suggests, or conflicts.", "X_comment": "Requires event_triggers, introduced in 9.3", - "X_comment": "cat_tools: requires extension support, added in 0.2.1", + "X_comment": "cat_tools: requires cat_tools.routine__parse_arg_types_text, added in 0.3.0", "prereqs": { "build": { "requires": { "PostgreSQL": "9.3.0", - "cat_tools": "0.2.1" + "cat_tools": "0.3.0" } }, "runtime": { diff --git a/META.json b/META.json index ba237c7..70608a2 100644 --- a/META.json +++ b/META.json @@ -73,13 +73,13 @@ "X_comment": "Valid keys for 'prereqs' are configure, build, runtime, or test.", "X_comment": "Valid keys for 'requires' are requires, recommends, suggests, or conflicts.", "X_comment": "Requires event_triggers, introduced in 9.3", - "X_comment": "cat_tools: requires extension support, added in 0.2.1", + "X_comment": "cat_tools: requires cat_tools.routine__parse_arg_types_text, added in 0.3.0", "prereqs": { "build": { "requires": { "PostgreSQL": "9.3.0", - "cat_tools": "0.2.1" + "cat_tools": "0.3.0" } }, "runtime": { diff --git a/RELEASE.md b/RELEASE.md index c93afd7..92b4fb4 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -34,13 +34,35 @@ Keep the next release ready to cut at any time: This way, a release is just renaming things — see step 2 below — not writing a changelog or an upgrade path from scratch under time pressure. +## Critical: never cut a release while CI needs a git-source dependency override + +The `Makefile`'s `cat_tools` target normally does a plain `pgxn install` — but +CI currently sets `CAT_TOOLS_GIT_REF` (see `.github/workflows/ci.yml`'s +top-level `env:`) to build cat_tools from a git ref instead, because PGXN's +published cat_tools doesn't yet have the version this distribution actually +requires. While that's true, `META.in.json`'s declared `cat_tools` floor +isn't actually satisfiable via `pgxn install` — cutting a release in that +state produces a real, publishable zip that can't actually be built by +anyone who downloads it from PGXN. + +**Before starting step 1 below**, check whether `ci.yml` still sets +`CAT_TOOLS_GIT_REF` (or `CAT_TOOLS_SKIP_INSTALL`) to a non-empty value. If it +does, stop — wait for the real dependency version to land on PGXN (and +revert `ci.yml`'s override back to unset) before proceeding. Checking +`ci.yml`'s actual value is the real signal here, not whether the Makefile +*declares* the variable — `CAT_TOOLS_GIT_REF` always exists in the Makefile +now, as a normally-empty, opt-in override; its mere existence doesn't mean +anything is pinned. + ## Cutting a release 1. Make sure `master` is in the state you want released, and CI is green. **Caveat:** as of this writing, CI passing doesn't actually mean the test suite passed — see "CI doesn't fail on test failures" below. Until that's fixed, also eyeball the actual `pg_regress` output in the CI logs (or run - `make test` locally), not just the green checkmark. + `make test` locally), not just the green checkmark. **Also check for a + dependency override** — see "Critical: never cut a release while CI needs + a git-source dependency override" above — before proceeding. 2. Rename the accumulated `STABLE` markers to the real version number: - Edit `META.in.json`: bump the top-level `version` field AND the matching