Adopt the stable pseudo-version convention - #42
Merged
jnasbyupgrade merged 1 commit intoAug 12, 2026
Merged
Conversation
Standalone from issue Postgres-Extensions#14's actual fix: default_version was pinned at a real, already-released version number (test_factory: 0.5.0, test_factory_pgtap: 0.1.0) the whole time between releases, meaning any ordinary source edit would silently regenerate -- and corrupt -- that frozen, already-shipped version's install script via pgxntool's own auto-generation. Set default_version = 'stable' in both control files so edits regenerate a disposable sql/<ext>--stable.sql instead. Added a genuine no-op update script for each extension (sql/test_factory--0.5.0--stable.sql, sql/test_factory_pgtap--0.1.0--stable.sql): Postgres's version-graph resolution requires an actual file to exist for ALTER EXTENSION ... UPDATE to have any path at all, regardless of whether its content would be a no-op (confirmed directly: without it, "has no update path from version 0.5.0 to version stable"). This distribution provides two extensions, so both get one, kept between releases regardless of which one(s) a given change actually touches -- that's what lets a release decide per-extension whether it needs a new version at all, by inspecting whether its own file has real content (see the forthcoming ../ai/RELEASE.md update for the full procedure). Gitignored the generated current-snapshot files (sql/test_factory--stable.sql, sql/test_factory_pgtap--stable.sql) -- named exactly, not via a sql/*--stable.sql glob, which also matches across the update scripts' second -- and would incorrectly sweep those up too (caught directly: they silently stopped showing as untracked after creation). Added .gitattributes marking that same pattern export-ignore instead, where the double-dash ambiguity is actually safe: by archive time, any extension that DID change already had its update script renamed away from that name, so only genuine no-ops can still match it -- verified directly with git archive | tar -tf -. Fixed bin/test_existing's version assertion, which compared against make -s print-PGXNVERSION (META.json's distribution version, still the real semver, never affected by default_version) instead of make -s print-EXTENSION_test_factory_VERSION (which tracks default_version directly) -- guaranteed to mismatch once default_version stopped equaling the distribution version. Verified locally on PG12 and PG17: fresh and update modes both pass, a real bin/test_existing run-suite both reports installed=expected='stable' and passes, and git archive includes the real versioned files while excluding both no-op stable-update scripts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
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. Comment |
jnasbyupgrade
merged commit Aug 12, 2026
6c09a22
into
Postgres-Extensions:master
21 of 29 checks passed
jnasbyupgrade
added a commit
to jnasbyupgrade/test_factory
that referenced
this pull request
Aug 12, 2026
… merged to master Merged upstream/master (which now has Postgres-Extensions#42's stable-pseudo-version work) into this branch. The merge itself resolved cleanly for the control files (default_version='stable' from master combined with superuser=false from this branch, on non-overlapping lines), but silently kept this branch's own corrupted sql/test_factory--0.5.0.sql instead of master's correct one -- git's merge doesn't know that file is supposed to be immutable, so a clean textual merge isn't the same as a correct one. Restored it to match master exactly. Replaced Postgres-Extensions#42's no-op sql/test_factory--0.5.0--stable.sql placeholder with the real GRANT-if-missing content -- this branch is "the first SQL-touching PR since the last release" per ../ai/RELEASE.md, so it's responsible for populating this file for real, which is also the signal the new multi-extension release procedure uses to decide test_factory needs a version bump next release (test_factory_pgtap doesn't, since its own placeholder stays a genuine no-op). Replaced test/install/load.sql with the version that splits update-mode role handling from fresh-mode: installing the genuinely-unfixed real 0.5.0 (test_factory VERSION '0.5.0') cannot succeed as a non-superuser -- that's the original bug, not a versioning artifact -- so update mode stays on the ambient/superuser role throughout, while only fresh mode switches to the disposable non-superuser installer (which already fully covers the non-superuser install path). Moved the issue Postgres-Extensions#14 regression check into the fresh-mode branch specifically, since it was checking the wrong thing under update mode's ambient role. Verified locally on PG12 and PG17: fresh and update modes both pass, sql/test_factory--0.5.0.sql and sql/test_factory_pgtap--0.1.0.sql remain byte-identical to what shipped, and `make` no longer touches either. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
stablepseudo-version convention (per../ai/RELEASE.md):default_versionin bothtest_factory.controlandtest_factory_pgtap.controlnow sits at the literal string'stable'between releases, instead of a real, already-released version number.sql/test_factory.sqlwould silently regenerate -- and corrupt -- the frozen, already-shippedsql/test_factory--0.5.0.sql(exactly what happened while developing Fix CREATE EXTENSION on PG16+ for non-superuser installs (#14) #18, before this fix existed).sql/test_factory--0.5.0--stable.sql,sql/test_factory_pgtap--0.1.0--stable.sql) -- required forALTER EXTENSION ... UPDATEto have any path at all, confirmed directly (has no update path from version 0.5.0 to version stablewithout it)..gitattributesto exclude the (currently no-op) update scripts from release archives.bin/test_existing's version assertion, which compared against the distribution version (unaffected bydefault_version) instead of the extension's actualdefault_version.This is intentionally not stacked on #18 -- it's a standalone versioning-hygiene fix that should land on
masterdirectly, independent of issue #14's actual fix.Test plan
make lintpasses.bin/test_existing run-suitereportsinstalled='stable' expected='stable'and passes.git archive HEAD | tar -tf -includes the real versionedsql/*files and excludes both no-op--stable.sqlupdate scripts.