Re: Versioning policy PgJDBC - discussion - Mailing list pgsql-jdbc

From Dave Cramer
Subject Re: Versioning policy PgJDBC - discussion
Date
Msg-id CADK3HH+Dr8hkX_BzJtVbb9BmO7RJ_FH=5HvFGYGP=HFb0-Xn9g@mail.gmail.com
Whole thread Raw
In response to Re: Versioning policy PgJDBC - discussion  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Responses Re: Versioning policy PgJDBC - discussion
List pgsql-jdbc
This is from one of the packagers:

I'd be more concerned with dependencies in the Java/Maven world. If
anyone was a dependency in there like jdbc-postgresql >= 9, you'll
kill them. (This is not a problem in the Debian version number
namespace because 1:4 > 9, but unless you'd be using 1:4.2.0 in the
Maven world as well...)

And the other

I'm in favor of that. Even I, as a packager, almost fail all the times when I
see "9.4" there.


I think the maven issue is real, which may put Jorge's idea in the lead?





On 25 November 2016 at 14:02, Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:
On 26/11/16 01:08, Vladimir Sitnikov wrote:

>We've changed the numbering scheme once already

AFAIK, the change from 9.4-1210 to 9.4.1211 was made to follow common convention where version number is separated with dots.

I would agree that it is still common for end-users to confuse 9.4 part with PostgreSQL version.

My instinctive reaction IS to think that the 9.4 refers to the pg version, though i know it is not for several years already!!!

I suggest that credit should be given to Douglas Adams who wrote THGTTG, for enlightening us as to the significance of '42' as the answer to 'the Ultimate Question of Life, the Universe and Everything'! See: http://hitchhikers.wikia.com/wiki/42

I once had to construct some indexes to Index Sequential files on an ICL mainframe, shortly after the BBC had aired the THGTTG, and at least 3 of the index keys turned out to be 42 bytes long - suspicious omens???




So moving to pgjdbc 42.0.0 would probably make sense.

Just in case: for current pgjdbc 9.4.1212,   "9.4" mean nothing. "1212" is just a sequence number.
So 42.0.0 would not harm much.

However, it would enable us to use 42.0.1 vs 42.1.0 for "bugfix" vs "new features" releases.
Current pgjdbc versioning scheme does not leave much room for pgjdbc 9.5.0 or alike.
+1


Vladimir

пт, 25 нояб. 2016 г. в 14:52, Dave Cramer <pg@fastcrypt.com <mailto:pg@fastcrypt.com>>:
[...]


Cheers,
Gavin


pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: Versioning policy PgJDBC - discussion
Next
From: Jorge Solórzano
Date:
Subject: Re: Versioning policy PgJDBC - discussion