Why so many active release tracks? Any reason(s) to not just use the latest?

[CharlieReitzel]

Looking at the download page, https://jdbc.postgresql.org/download/, you can see 2 active tracks right there: 42.7.x and 42.6.x.

The descriptive text for both is identical. So, why would one pick one or the other? If the advice is to always use the latest, why keep releasing updates to earlier tracks?

Since pgSQL always uses major version 42.x.x, can we expect breaking changes between minor versions, e.g. 42.6.2 vs 42.7.1?

Looking at the Change Log page, https://jdbc.postgresql.org/changelogs/, it appears that several minor versions have been updated recently.

Seems like a few words on both the downloads and change log pages would be helpful here. Is there another source, besides digging through pull requests to get this info?

My basic assumption here is that folks have good reasons for keeping multiple release tracks alive.

Also, since we're all constantly updating our dependencies these days, this question has become more than idle curiosity.

Thanks for any info!

[davecramer]

We only backpatch security fixes and this was a security fix, GHSA-24rp-q3w6-vc56

[laurenz]

Why keep 42.6 around and backpatch to it? Are there any incompatibilities that may keep you from upgrading to 42.7? I guess there are, but where are they documented?

[davecramer]

@laurenz because people may not be using 42.7 and forcing them to upgrade due to a security issue is a challenge

[vlsi]

Here are some challenges:
a) Imagine the system uses 42.2.0, and imagine the "current" version is 42.9.0. Imagine a CVE arrives that is applicable to all the versions. Even though individual changes like 42.2.0 -> 42.3.0, 42.3.0 -> 42.4.0 might be small, there might be many subtle incompatibilities along the way which might make the upgraded application fail or silently corrupt data. If we force everybody to fully retest their systems just in order to fix security, it would be too much hassle without extra gain.

Remember, the last CVE was CVSS 10 of 10. Sure people got notifications from their vulnerability scanners, and sure they needed an upgrade path. Asking everybody to upgrade to "the latest master branch" just in order to fix CVE 10 is wrong from my point of view.

b) There are cases when people can't upgrade versions due to policy reasons. For instance, Spring Boot fixes minor versions, and they can't upgrade minor version to fix security issue. Check out an example in #2599 (comment)
Even though it might sound doubtful, that is a policy they follow, and they follow it for many dependencies, not just pgjdbc.

c) pgjdbc releases are not ideal. Sometimes we happen to unwillingly introduce regressions. For instance, 42.7.0 had several regressions which were fixed in a subsequent release, https://github.com/pgjdbc/pgjdbc/releases/tag/REL42.7.0. I might easily imagine there might be undiscovered regressions.

d) If the newer driver version includes intentional changes of the behavior, then it would be non-trivial for the app developer to upgrade, especially if they absorb many changes in a single go.

e) There's a LOT of log4j 1.x usages in many systems. Nobody will ever upgrade to "log4j 2.x" (which is incompatible with 1.x) just to "fix security issues". I believe the current log4j team is doing wrong by not fixing known CVEs in log4j 1.x. The CVEs are trivial to fix, and it is not hard to release. So I would keep log4j 1.x "EOL" as an anti-pattern of how projects should fix security issues.

[sehrope]

I think a lot of is that historically we've done it this way and users have been accustomed to it. Also, given the 20+ year history of people using this driver, there's a lot of applications using this driver, and the user base of those application is fairly risk averse.

The JDBC spec and the driver should be fully backwards compatible and it's highly encouraged that users stick to the latest version of the driver. I'd love to get to a point where we scrap the older release lines and have a single main branch. Releases would just be point in time snapshots of master that we consider to be ready to release (with any bug fixes or features rolled into the next version).

There's some legacy JDK version issues that prevent that for the more ancient versions, but it should be (technically) doable for the more recent ones were we already require a non-EOL JDK version. One day...

[laurenz]

people may not be using 42.7 and forcing them to upgrade due to a security issue is a challenge

Why is it a challenge? Probably because of incompatible changes. Is there a list of these incompatibilities anywhere?

[vlsi]

Please use replies instead of creating new "answers" every time. "suggesting new answers" creates threads which are hard to read as different answers are not aligned into a coherent thread.

[laurenz]

Thanks for telling me. I wasn't aware of that.