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/Makefile b/Makefile index 033cf30..8b37be9 100644 --- a/Makefile +++ b/Makefile @@ -11,7 +11,34 @@ $(DESTDIR)$datadir)/extension/extension_drop_test.control: deps: cat_tools install: deps +# extension_drop.sql calls cat_tools.routine__parse_arg_types_text(), which only +# exists starting at cat_tools 0.3.0. PGXN's published cat_tools listing is +# stuck at 0.2.1 from 2017 (the old decibel/cat_tools distribution) and was +# never updated for the Postgres-Extensions/cat_tools fork; `pgxn install +# cat_tools` therefore installs an ancient 0.2.1 lacking the function we need +# (and carrying a pre-omit_column-fix catalog query that breaks on PG12+). +# 0.3.0 itself has not been tagged/published to PGXN yet -- only 0.2.2/0.2.3 +# are there, and even 0.2.3 predates this function. So PGXN isn't a usable +# install source right now. +# +# Building straight from a git ref instead of PGXN is a supported way to +# depend on an extension here, not just a one-off hack -- reach for it again +# whenever a dependency's real state has moved ahead of what's tagged on +# PGXN. What IS temporary is depending on cat_tools this way at all: +# CAT_TOOLS_GIT_REF tracks cat_tools' `master` directly rather than a pinned +# commit, since the function we need doesn't exist on any tagged release, so +# there's nothing more stable to pin to yet. Once 0.3.0 is tagged and +# published to PGXN, revert *this target* to a plain +# `pgxn install 'cat_tools>=0.3.0' --sudo`; leave the git-source mechanism +# itself in place for reuse if this happens again. +CAT_TOOLS_GIT_REF = master +CAT_TOOLS_BUILD_DIR = tmp/cat_tools-build + .PHONY: cat_tools cat_tools: $(DESTDIR)$(datadir)/extension/cat_tools.control $(DESTDIR)$(datadir)/extension/cat_tools.control: - pgxn install 'cat_tools>=0.2.1' --sudo + rm -rf $(CAT_TOOLS_BUILD_DIR) + git clone https://github.com/Postgres-Extensions/cat_tools.git $(CAT_TOOLS_BUILD_DIR) + cd $(CAT_TOOLS_BUILD_DIR) && git checkout $(CAT_TOOLS_GIT_REF) + $(MAKE) -C $(CAT_TOOLS_BUILD_DIR) install PG_CONFIG=$(PG_CONFIG) DESTDIR=$(DESTDIR) + rm -rf $(CAT_TOOLS_BUILD_DIR) diff --git a/README.md b/README.md index c38c877..29a8720 100644 --- a/README.md +++ b/README.md @@ -4,7 +4,13 @@ Run custom commands when an extension is dropped. By default, `DROP EXTENSION` simply drops all the objects the extension owns; this lets you register additional SQL to run when a given extension is dropped. -Requires [cat_tools](https://pgxn.org/dist/cat_tools/) >= 0.2.1. +Requires [cat_tools](https://github.com/Postgres-Extensions/cat_tools) >= 0.3.0. +Note: as of this writing, cat_tools 0.3.0 has not been tagged/published to +PGXN yet, so the `cat_tools` build dependency is temporarily installed +straight from its `master` branch rather than via `pgxn install` -- see the +`Makefile`. This will revert to a plain `pgxn install` once 0.3.0 is +published; building from a git ref is itself a supported fallback for this +kind of gap, not a one-off hack. ## Functions diff --git a/RELEASE.md b/RELEASE.md index c93afd7..39b6c70 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -11,6 +11,33 @@ Releases use pgxntool's built-in `make tag`/`make dist` mechanics to produce a be uploaded to PGXN Manager by hand. See "Future: CI automation" below for the planned upgrade path. +## Critical: never cut a release while a dependency is pinned to a git source + +Some dependencies are occasionally built from a pinned git ref instead of a +real PGXN-published version, when the version we actually need hasn't been +tagged yet (see e.g. the `Makefile`'s `cat_tools` target and +`CAT_TOOLS_GIT_REF`). While a pin like that is active, this distribution's +declared dependency floor (`META.in.json`'s `prereqs`) isn't actually +satisfiable via `pgxn install` — cutting a real release in that state +produces a citable, default-installable zip (`pgxn install` needs no special +flags to fetch a `stable` release) that can't actually be built by anyone who +downloads it from PGXN. + +**Before starting step 1 below**, grep the `Makefile` for any +`_GIT_REF`/`_GIT_SHA`-style pinned-dependency variables. If any exist, stop — +either wait for the real dependency version to land on PGXN, or otherwise +resolve the pin, before proceeding. + +`bin/in_release` exists to help catch this: it exits true when +`HISTORY.asc`'s top heading is a real version number rather than the +`STABLE` placeholder used while changes are still accumulating (see +"Ongoing development" below) — i.e., true exactly when we're sitting at (or +about to cut) a release rather than mid-development. A pin existing while +`bin/in_release` is true is exactly the state to avoid. This isn't wired into +CI yet — that would need a generic, machine-checkable way to know "a pin +exists" across whatever dependency needs one at the time, not just +`cat_tools` specifically — so for now it's a manual check. + ## Ongoing development (every PR, between releases) Keep the next release ready to cut at any time: @@ -40,7 +67,9 @@ a changelog or an upgrade path from scratch under time pressure. **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 pin** — see "Critical: never cut a release while a dependency + is pinned to a git source" 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 diff --git a/bin/in_release b/bin/in_release new file mode 100755 index 0000000..8e14d72 --- /dev/null +++ b/bin/in_release @@ -0,0 +1,9 @@ +#!/bin/sh +# True (exit 0) when HISTORY.asc's top heading is a real released version +# number rather than the `STABLE` placeholder used while changes are still +# accumulating toward the next release -- i.e., true exactly when we're +# sitting at (or about to cut) a release rather than mid-development. See +# RELEASE.md. +set -eu +cd "$(dirname "$0")/.." +[ "$(head -n1 HISTORY.asc)" != "STABLE" ]