Add RELEASE.md and HISTORY.md, switch from release branches to tags - #12
Merged
Conversation
cat_tools (Postgres-Extensions/cat_tools) already has a written release process; copy it here as-is before adapting it to count_nulls's own conventions in a follow-up commit, so the diff between "what cat_tools does" and "what count_nulls actually needs" stays easy to review.
count_nulls doesn't share several pieces of cat_tools's release machinery: there's no .sql.in generation (install scripts are committed directly, so there's no generated-script-omission choice to make), no HISTORY.asc changelog file, and no `stable` pseudo-version scheme (cat_tools's sql.mk feature) to leave and return to around a release, so the whole warning box and the "return master to stable" step drop out. It also has no prior release yet, so the tag-naming example uses count_nulls's own version instead of referencing cat_tools's existing 0.2.2 tag, and the removed 0.2.3-specific catalog-view caveat goes with it. Added a `make test-update` check in the verify steps, since that's how count_nulls actually exercises the update path end to end.
|
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:
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
The previous commit dropped the stable-pseudo-version dance and the changelog step entirely, on the wrong assumption that neither applied to count_nulls - checking cat_tools' actual control-file history showed that scheme was never really built there either (its own RELEASE.md describes a feature that doesn't exist), and count_nulls didn't have a HISTORY file to reference. Both are worth having for real here, so this adds them properly instead: default_version now distinguishes from the PGXN distribution version (count_nulls has already shipped one release, 0.9.7, where only the distribution version moved), a new safety-check step verifies committed version files haven't been touched after their own release before trusting the stable dance to prevent that going forward, and HISTORY.md gives the changelog step somewhere to write to. Sized the "commit every version file" guidance to count_nulls' own scale (~90-line source, half a dozen versions) rather than copying cat_tools' size-driven trade-off wholesale. Also switched count_nulls itself from release branches to tags to match: 0.1.0 through 0.9.7 were previously tracked as branches (a leftover pre-tag convention), now backfilled as annotated tags at the same commits and the branches deleted, so `make tag` is the one real release mechanism referenced in this doc.
jnasbyupgrade
changed the title
Reconstructed one entry per real release (0.1.0 through 0.9.7) from each tag's actual diff, at pgxntool/HISTORY.asc's level of detail - a paragraph or == per-change section, not just a version bump line. Also credits the one real fix since 0.9.7 (dropping a redundant, unconditional client_min_messages override in the install script) under the pending "stable" section.
jnasbyupgrade
marked this pull request as ready for review
July 24, 2026 21:42
Replaced count_nulls-specific naming throughout RELEASE.md with an <extension> placeholder so other repos can adopt this doc with minimal find-and-replace, keeping only the intro paragraph's 0.9.7 anecdote as a concrete, repo-specific illustration of the distribution-vs-extension-version split. Also generalized the version-file-drift safety check, the size-based "commit every version file" guidance, and the tag-migration note in step 6, replacing count_nulls' own specific historical details with the general pattern they illustrate. HISTORY.md's pending section is now headed 1.0.0 instead of stable, since count_nulls.control is already stamped at 1.0.0 - an intentional exception for this first release while adopting the full process; every release after this one goes through the real stable dance.
…xtension>
The previous pass over-mechanically substituted <extension> for every mention
of count_nulls, including in plain-English prose where no placeholder was
needed at all, and split the L7 paragraph awkwardly between generic
placeholder text and a specific count_nulls anecdote mid-paragraph. Reworded
throughout: the title and opening sentence no longer need the extension name
at all ("This extension makes use of pgxntool" rather than claiming to build
on/extend it), and every other prose reference became plain English ("the
extension's .control file", "the extension's own entry under provides")
instead of a placeholder. Kept <extension> only where it's a literal,
copy-pasteable file-naming pattern (shown once each, not repeated per bullet).
Reverted the L7 paragraph to name count_nulls throughout, not just its second
half - the whole paragraph is a real, specific illustration of the
distribution-vs-extension-version split, not generic instructional text.
jnasbyupgrade
added a commit
that referenced
this pull request
Jul 29, 2026
… fork The gate checked github.event.pull_request.head.repo.owner.login == 'jnasbyupgrade', written back when PRs came from that personal fork. Now that the convention is to push branches directly to this repo instead (never the fork), every PR's head repo owner is Postgres-Extensions, not jnasbyupgrade - so the condition never matched and claude-review silently skipped on every single PR this session (#12, #13, #14 all show it as skipped). Replaced with head.repo.full_name == github.repository, which is actually a tighter trust boundary than the old check: it only allows PRs whose head branch lives in this exact repo, requiring push access here, rather than naming one specific external fork as trusted.
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.
Add a written release process for count_nulls, adding RELEASE.md and HISTORY.md and switching the project from release branches to real git tags to match.
RELEASE.md started as a verbatim copy of cat_tools's own release doc (Postgres-Extensions/cat_tools), then got adapted once a few of its assumptions turned out not to hold. cat_tools' doc describes a
stable-pseudo-version scheme (master'sdefault_versionnormally sitting at the literal stringstableso ordinary source edits never touch a frozen, already-released version's install file) as though it's implemented via asql.mkit ships - checking cat_tools' actualcat_tools.controlhistory showsdefault_versionhas always been a real literal version, neverstable; the scheme is aspirational documentation for something that was never actually built there. count_nulls' own build already decouples the PGXN distribution version (META.in.json) from the extension's own version (count_nulls.control'sdefault_version) by design, so implementingstablefor real here is straightforward - I built and verified it (install at a real version,ALTER EXTENSION UPDATEreachesstable, functions still work) on a separate branch, but landing it is step 7 of this same doc, done right after the next real release ships rather than ahead of time.The doc also adds a safety-check step: before trusting the stable dance to protect committed version files going forward, verify each one's last-touching commit predates its own release. That surfaced that PGXN.org (not this repo's own git history) is the only authoritative record of what's actually shipped: count_nulls has never had a single git tag, and its 9 real releases (
0.1.0through0.9.7) were instead tracked as git branches, a leftover pre-tag convention. Also worth knowing:0.9.7on PGXN was a distribution-version-only bump (packaging/CI fixes, no SQL changes) - the extension's own version stayed at0.9.6, which is exactly the kind of divergencestableis meant to make routine instead of a one-off.To actually make tags authoritative rather than just document the intent, this backfills annotated tags for all 9 real releases at the same commits their release branches pointed to (verified linear, each a clean ancestor of the next, dates matching PGXN's listing) and deletes those now-redundant branches, so
make tagis the one real release mechanism from here on.HISTORY.md is new - count_nulls didn't have a changelog file before. Seeded with an empty top
stablesection per RELEASE.md's changelog step, and a pointer to PGXN.org for the pre-existing releases it predates.