Draft back-branch release notes are up

2026-05-09 · opus 4.7

Overview

This thread is a routine administrative announcement from Tom Lane (PostgreSQL core committer and long-time release manager) notifying the pgsql-hackers community that draft release notes for an upcoming back-branch minor release have been committed to the git repository. It is not a technical design discussion but rather a standard step in PostgreSQL's release engineering workflow.

Context: PostgreSQL's Back-Branch Release Process

PostgreSQL ships quarterly minor releases across all supported major versions (typically five active branches at any given time, e.g., 14.x through 18.x). These minor releases bundle bug fixes, security patches, and occasional behavioral corrections that have been backpatched from master. A critical artifact of each minor release is the release notes, which document every user-visible change per branch.

Tom Lane has historically served as the primary author of PostgreSQL release notes. The workflow he follows is well-established:

Review every commit backpatched since the last minor release across all live branches.
Classify changes by user visibility (skipping purely cosmetic or internal refactors).
Group related fixes and write prose entries in the DocBook release-N.N.sgml style.
Commit the draft to the master branch (and eventually cherry-pick to back branches).
Solicit review from hackers before the release wrap.

The single message in this thread is step 4/5: Tom has pushed the draft (commit 122adefc94a4dc4e97b4fd5c3328e7dc5b58ebd0) and is giving the community a review window ending Sunday — typically a 4–5 day window before the release is tagged on a Monday for Thursday public release.

Why This Matters Architecturally

While the email itself contains no technical content, the process it represents is load-bearing for PostgreSQL's reputation for release quality:

Accuracy of attribution and behavior description: Release notes are the authoritative record of what changed. Incorrect descriptions of a bug fix can mislead DBAs into upgrading (or not upgrading) based on false premises. Authors of individual patches are best positioned to verify that Tom's summary accurately describes the fix's scope, affected versions, and required post-upgrade actions (e.g., REINDEX, catalog fixes).
Identification of migration hazards: Back-branch releases occasionally include fixes that require manual DBA action (e.g., reindexing after a collation or GIN fix, re-creating views after a parser bug). The review window is the last chance to ensure such hazards are flagged prominently.
Security boundary: If any CVE-class fixes are in the batch, the release notes must describe them in a way that informs users without giving attackers a head start. This is a sensitive editorial judgment.

Review Dynamics

The "send comments/corrections by Sunday" sign-off is intentionally terse because the workflow is so well-understood. Patch authors scan the notes for their own commits; committers whose areas were touched verify technical accuracy; documentation-focused contributors catch wording and markup issues. Tom integrates feedback directly rather than through a patch review thread, given the tight timeline.

Tom's authority here is uncontested — he has written the bulk of PostgreSQL release notes for roughly two decades, and his judgment on what rises to the level of a user-visible note is treated as definitive barring specific objections.

Timeline and Artifact

The relevant artifact is commit 122adefc94a4dc4e97b4fd5c3328e7dc5b58ebd0 on master. Review would be expected to close within approximately 4 days of the 2026-05-08 posting, aligning with a mid-May 2026 minor release (consistent with PostgreSQL's May/August/November/February cadence).

Takeaways

This thread is procedural rather than technical. Its significance lies in illustrating: