Rename default_version from 1.0.0 to stable - #26
Open
jnasbyupgrade wants to merge 2 commits into
Open
Conversation
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>
|
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 |
META.in.json/META.json: plain version substitution (stable), not a rollback to 0.1.1 with explanatory X_comment lines. HISTORY.asc: just rename the heading, no new changelog entry for an internal versioning-label correction. Also gitignore sql/extension_drop--stable.sql specifically -- it's a mechanical copy of sql/extension_drop.sql for as long as default_version is the stable pseudo-version, so committing it duplicates that file. Real per-version files (once actually released) stay tracked.
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.
Why
extension_drop.control'sdefault_versionhas said1.0.0since an earlier, incomplete release-prep PR -- but1.0.0was never actually tagged or published to PGXN. The only real release ever published was0.1.1(2017). Carrying an unreleased version number asdefault_versionis misleading: it implies a release happened when it didn't.This renames it to the
stablepseudo-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 to0.1.1(the real last released version), with anX_commentexplaining the invariant (don't re-bump until an actual release, seeRELEASE.md)HISTORY.asc: rename the1.0.0heading toSTABLE, add an entry explaining the renameBase branch
Based directly on
fix-cat-tools-install(#10), as a sibling oftest-install-foundation(#19) rather than stacked on top of it. Verifiedextension_drop.control,HISTORY.asc,META.in.json,META.json, andsql/extension_drop--1.0.0.sqlare all untouched betweenfix-cat-tools-installandtest-install-foundation-- this rename is fully independent of thetest/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 (recoveringsql/extension_drop--0.1.1.sql, authoring the0.1.1->stableupdate-diff script, and theextension-update-testCI job). That infrastructure logically depends on this rename having landed first (the update-diff script's target isstable), so #22 is being rebased to depend on this PR instead of duplicating the rename.Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com