pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feedFrom: vlsi (@vlsi) <[email protected]>
To: pgjdbc/pgjdbc <[email protected]>
Subject: [pgjdbc/pgjdbc] PR #4079: docs: spell out the proactive-security window in SECURITY.md
Date: Tue, 19 May 2026 13:48:57 +0000
Message-ID: <[email protected]> (raw)
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"):
<img width="913" height="633" alt="updated compatibility page" src="https://github.com/user-attachments/assets/355d77c5-2964-45d8-b1c5-ed89ab44a7ff"; />
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: github://pgjdbc/pgjdbc
Cc: [email protected], [email protected]
Subject: Re: [pgjdbc/pgjdbc] PR #4079: docs: spell out the proactive-security window in SECURITY.md
In-Reply-To: <<[email protected]>>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox