Message-ID: From: "vlsi (@vlsi)" To: "pgjdbc/pgjdbc" Date: Tue, 19 May 2026 13:48:57 +0000 Subject: [pgjdbc/pgjdbc] PR #4079: docs: spell out the proactive-security window in SECURITY.md List-Id: X-GitHub-Author-Id: 213894 X-GitHub-Author-Login: vlsi X-GitHub-Issue: 4079 X-GitHub-Labels: documentation X-GitHub-Repo: pgjdbc/pgjdbc X-GitHub-State: open X-GitHub-Type: pull_request X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/4079 Content-Type: text/plain; charset=utf-8 Names the policy ("five years past the `.0` of the next minor"), adds a row for older-but-still-in-window 42.x lines, and links to the Compatibility page for the resolved per-line dates. Also cleans up a few typos in the prose. --- Here's a quote from PostgreSQL versioning page: > https://www.postgresql.org/support/versioning/ > The PostgreSQL Global Development Group supports a major version for 5 years after its initial release. After this, a final minor version will be released and the software will then be unsupported (end-of-life). This hints "5 years" might be reasonable for pgjdbc as well. --- ## Why a proactive-security window? This PR formalises a policy the project has effectively been operating under for a while: older release lines get proactive security backports, not "on request if we feel like it." The compatibility page surfaces the resolved per-line date as Security until YYYY-MM. A proactive window matters because most pgJDBC users cannot respond to a CVE by jumping to the latest minor: 1. **Enterprises need to ship a security fix without taking a minor bump**. Regulated change-management makes "patch your CVE and upgrade two minors in the same window" a non-starter — users need to apply the security patch now on the line they're running, then plan the upgrade on their own schedule. 2. **Users stuck on older stacks** (legacy JVMs, old PostgreSQL servers, frozen application images) cannot freely move to a newer minor. A "just upgrade" answer doesn't reach them; they still need CVE coverage. 3. **The upgrade itself isn't always safe**. A newer minor occasionally carries a regression or a backward-incompatible behaviour change the user cannot work around inside a CVE deadline. Forcing the upgrade as the only path to a fix trades one fire for another. 4. **Downstream dependency policies block minor bumps**. Spring Boot, for instance, will not change the minor version of a transitive dependency inside a patch release. If they pin a pgJDBC line that has no security patch on its own minor, their downstream users cannot get the fix without violating Spring Boot's policy. A backport on the pinned line is the only path that works for the whole chain. The intent is the same line the existing prose draws — to separate "we are eager fixing bugs" from "we can roll security releases" — but stated as a concrete, time-bounded commitment users and downstream packagers can plan against. --- For the reference, here's how the compatibility page would look like under the updated conditions ("five years past the `.0` of the next minor"): updated compatibility page