Rename default_version from 1.0.0 to stable by jnasbyupgrade · Pull Request #24 · Postgres-Extensions/extension_tools

jnasbyupgrade · 2026-08-04T22:48:14Z

Why

extension_drop.control's default_version has said 1.0.0 since an earlier, incomplete release-prep PR -- but 1.0.0 was never actually tagged or published to PGXN. The only real release ever published was 0.1.1 (2017). Carrying an unreleased version number as default_version is misleading: it implies a release happened when it didn't.

This renames it to the stable pseudo-version (matching Postgres-Extensions/pg_count_nulls#13's convention) -- an honest label for "current unreleased source" -- until a real release is actually cut.

Changes

extension_drop.control: default_version = 'stable'
sql/extension_drop--1.0.0.sql -> sql/extension_drop--stable.sql (pure rename, no content change)
META.in.json / META.json: roll the version fields back to 0.1.1 (the real last released version), with an X_comment explaining the invariant (don't re-bump until an actual release, see RELEASE.md)
HISTORY.asc: rename the 1.0.0 heading to STABLE, add an entry explaining the rename

Base branch

Based directly on fix-cat-tools-install (#10), as a sibling of test-install-foundation (#19) rather than stacked on top of it. Verified extension_drop.control, HISTORY.asc, META.in.json, META.json, and sql/extension_drop--1.0.0.sql are all untouched between fix-cat-tools-install and test-install-foundation -- this rename is fully independent of the test/install/ harness work in #19, so there's no reason to require it as a prerequisite. This keeps the history as flat/parallel as possible.

Relationship to #22

This was split out of #22 (real-update-path), which bundled this rename together with the real update-path-testing infrastructure (recovering sql/extension_drop--0.1.1.sql, authoring the 0.1.1->stable update-diff script, and the extension-update-test CI job). That infrastructure logically depends on this rename having landed first (the update-diff script's target is stable), so #22 is being rebased to depend on this PR instead of duplicating the rename.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

The `1.0.0` label was aspirational -- it was never tagged or published to PGXN, despite `default_version` and HISTORY.asc naming it as a real released version. It was carried over from an earlier, incomplete release-prep effort that never actually cut a release. Rename to the `stable` pseudo-version (matching Postgres-Extensions/pg_count_nulls#13's convention) to stop implying a release that never happened, until a real one is actually cut: - extension_drop.control: default_version = 'stable' - sql/extension_drop--1.0.0.sql -> sql/extension_drop--stable.sql (pure rename, no content change) - META.in.json/META.json: roll the version fields back to 0.1.1 (the real last released version), with an X_comment explaining the invariant so it isn't re-bumped prematurely again - HISTORY.asc: rename the "1.0.0" heading to "STABLE" and add an entry explaining the rename Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

coderabbitai · 2026-08-04T22:48:21Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 6cb46d70-7ae8-435d-af3a-47bb0436424e

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

extension_drop's real 0.1.1 install script (2017) was never committed to this repo -- only ever generated as a PGXN dist build artifact and uploaded directly -- so no update-diff script has ever existed either, despite a real SQL change between 0.1.1 and the current `stable` source (removing redundant client_min_messages handling; see Postgres-Extensions#24, which renamed default_version from the never-released "1.0.0" to `stable` and is a prerequisite for this branch). That left anyone who actually installed 0.1.1 from PGXN with no path forward at all. - Recover the real 0.1.1 sql/extension_drop.sql from PGXN's dist archive (https://api.pgxn.org/dist/extension_drop/0.1.1/extension_drop-0.1.1.zip) and commit it as sql/extension_drop--0.1.1.sql. Add it to DATA explicitly (pgxntool's DATA wildcard only picks up the current version file and two-dash update scripts, not other historical single-version files -- Postgres-Extensions/pgxntool#48). - Author sql/extension_drop--0.1.1--stable.sql: the actual delta is just extension_drop__event_trigger() gaining one RAISE DEBUG line (found by diffing recovered 0.1.1 against current source). The client_min_messages removal and a cat_tools function rename (function__arg_types_text -> routine__parse_arg_types_text) both turned out to be install-script-only behavior with nothing persisted to replay. - Default TEST_UPDATE_FROM to 0.1.1 and wire up a real extension-update-test CI job: installs 0.1.1, plants the dependency guard, runs ALTER EXTENSION UPDATE, re-proves the guard survived, dynamically asserts the version landed at stable, then runs the pgTAP suite in update mode. Factored into bin/test_update_path.sh so it's runnable locally, not just inline CI YAML. Verified locally against PG17: 0.1.1 install -> guard blocks non-CASCADE drop -> ALTER EXTENSION UPDATE -> guard still blocks drop -> version lands at 'stable' -> full pgTAP suite passes in both fresh and update modes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

jnasbyupgrade · 2026-08-04T22:53:13Z

Closing and reopening from the org-repo branch (Postgres-Extensions/extension_tools:rename-1.0.0-to-stable) instead of my fork, for consistency with the rest of the PR stack (#10/#19/#20/#21/#22), which are all same-repo branches. Same commit, no content change.

extension_drop's real 0.1.1 install script (2017) was never committed to this repo -- only ever generated as a PGXN dist build artifact and uploaded directly -- so no update-diff script has ever existed either, despite a real SQL change between 0.1.1 and the current `stable` source (removing redundant client_min_messages handling; see #24, which renamed default_version from the never-released "1.0.0" to `stable` and is a prerequisite for this branch). That left anyone who actually installed 0.1.1 from PGXN with no path forward at all. - Recover the real 0.1.1 sql/extension_drop.sql from PGXN's dist archive (https://api.pgxn.org/dist/extension_drop/0.1.1/extension_drop-0.1.1.zip) and commit it as sql/extension_drop--0.1.1.sql. Add it to DATA explicitly (pgxntool's DATA wildcard only picks up the current version file and two-dash update scripts, not other historical single-version files -- Postgres-Extensions/pgxntool#48). - Author sql/extension_drop--0.1.1--stable.sql: the actual delta is just extension_drop__event_trigger() gaining one RAISE DEBUG line (found by diffing recovered 0.1.1 against current source). The client_min_messages removal and a cat_tools function rename (function__arg_types_text -> routine__parse_arg_types_text) both turned out to be install-script-only behavior with nothing persisted to replay. - Default TEST_UPDATE_FROM to 0.1.1 and wire up a real extension-update-test CI job: installs 0.1.1, plants the dependency guard, runs ALTER EXTENSION UPDATE, re-proves the guard survived, dynamically asserts the version landed at stable, then runs the pgTAP suite in update mode. Factored into bin/test_update_path.sh so it's runnable locally, not just inline CI YAML. Verified locally against PG17: 0.1.1 install -> guard blocks non-CASCADE drop -> ALTER EXTENSION UPDATE -> guard still blocks drop -> version lands at 'stable' -> full pgTAP suite passes in both fresh and update modes. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

jnasbyupgrade closed this Aug 4, 2026

Navigation Menu

Uh oh!

Rename default_version from 1.0.0 to stable - #24

Rename default_version from 1.0.0 to stable#24
jnasbyupgrade wants to merge 1 commit into
Postgres-Extensions:fix-cat-tools-installfrom
jnasbyupgrade:rename-1.0.0-to-stable

jnasbyupgrade commented Aug 4, 2026

Uh oh!

coderabbitai Bot commented Aug 4, 2026

Review skipped

Uh oh!

jnasbyupgrade commented Aug 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

jnasbyupgrade commented Aug 4, 2026

Why

Changes

Base branch

Relationship to #22

Uh oh!

coderabbitai Bot commented Aug 4, 2026

Review skipped

Uh oh!

jnasbyupgrade commented Aug 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant