Versioning policy PgJDBC - discussion - Mailing list pgsql-jdbc

From Jorge Solórzano
Subject Versioning policy PgJDBC - discussion
Date
Msg-id CA+cVU8PMsQUachn6Ari2egdAJUA_ytFVgQAXk6u6c2fEW35MJQ@mail.gmail.com
Whole thread Raw
Responses Re: Versioning policy PgJDBC - discussion
List pgsql-jdbc
​I want to bring a healthy discussion about the current version policy ​of PgJDBC, this is due the fact that the current versioning policy is somewhat misleading.

As many are aware the PostgreSQL Project has decided to switch to a new version numbering policy. The current version number composition is: Major1.Major2.Minor (9.6.1) and the new will be just Major.Minor so the next major version will be just "10" (instead of 10.0). This decision was made because with that first number is that they have no clear criteria when to advance it.

In PgJDBC is even less clear when to advance the versioning. The current version number composition of pgjdbc is (was?) based on some kind of follow up of the PostgreSQL server version, so when a new release of Postgres was made the version number of pgjdbc was increased along with a release number. This was at least until the maven conversion, from the maven conversion only the release number was increased.

Essentialy was like this:
PgJDBC  -> PostgreSQL
9.0-801 (2010-09) -> 9.0 (2010-09)
9.1-901 (2011-04) -> 9.1 (2011-09)
9.2-1000 (2012-09) -> 9.2 (2012-09)
9.3-1100 (2013-11) -> 9.3 (2013-09)
9.4-1200 (2015-01) -> 9.4 (2014-12)
9.4.1207 (2015-12) -> 9.5 (2016-01) * Maven conversion
9.4.1209 (2016-07) -> 9.6 (2016-09) * Full test suite passes against PostgreSQL 9.6
9.4.1210 (2016-09) -> 10? (2017-?)

So it looks there is a common pattern that was broke with maven conversion, but anyway trying to keep version on pair with server is nonsense.

Even in public news the release reflected is just the release number "JDBC 1212 Released".

For many people, this is confusing as they tend to relate the support for a particular version with the version of the driver (https://www.postgresql.org/message-id/flat/2d67afa8-03bc-f231-98d9-f80e9ee7b4e5%401energy.at#2d67afa8-03bc-f231-98d9-f80e9ee7b4e5@1energy.at) and the answer is "The latest driver 1211."

So I propose a change in versioning following more close a Semantic Versioning (http://semver.org/) with some changes using only 2 version numbers:

Given a version number MAJOR.MINOR, increment the:

  1. MAJOR version when you make incompatible API changes, *or a major feature change is introduced*.
  2. MINOR version when you add functionality in a backwards-compatible manner, and when you make backwards-compatible bug fixes.

Since we aim to support very old versions of Postgres up to 8.2, there should be no discussion about using the latest version on an old version of the server. "What version do I use for Postgres 8.3? Use the latest. For Postgres 9.1? Use the latest."

So the big question would be, on which version should we start on? for me the obvious choice is 13.0, let me explain, most versions comes with a release number, for 9.0 is 801 wich can be translated to 8.1, and 9.3 is 1100 -> 11.0, and 9.4 is 1200 -> 12.0...

So the obvious choice is 13.0, why 13.0 and not 12.13 (release 9.4.1213)? there will (probably) be many new features (adaptive fetch size, replication protocol support, remove support for pg<8.2) on this release that should gain a MAJOR version increment, and anyway a change in versioning should require a full version increment on it own. 13.0 should be a good starting point since 13 > 9, so it obviously won't break any parser.

Why not 10.0? the first reason is that we don't want to keep a close relation with the server version, if we use 10.0 people will start to think that is the version for use with Pg10, the second reason is that we "lose" the release versioning increments of previous version, and since we are using that to point users (JDBC 1212 released) it makes more sense that the next news reads "JDBC 13.0 released" and not "JDBC 10.0 released" since users will relate 1212 with 12.12 more easily and 12.12 > 10.0 wich should be wrong.


This is an open discussion, any comments are welcome.


Regards,

pgsql-jdbc by date:

Previous
From: Vladimir Sitnikov
Date:
Subject: Re: Versioning policy PgJDBC - discussion
Next
From: Vladimir Sitnikov
Date:
Subject: Re: Versioning policy PgJDBC - discussion