Re: Versioning policy PgJDBC - discussion

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: Versioning policy PgJDBC - discussion
Дата
Msg-id CADK3HH+Dr8hkX_BzJtVbb9BmO7RJ_FH=5HvFGYGP=HFb0-Xn9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Versioning policy PgJDBC - discussion  (Gavin Flower <GavinFlower@archidevsys.co.nz>)
Ответы Re: Versioning policy PgJDBC - discussion
Список 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 по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: Versioning policy PgJDBC - discussion
Следующее
От: Jorge Solórzano
Дата:
Сообщение: Re: Versioning policy PgJDBC - discussion