Обсуждение: Versioning policy PgJDBC - discussion
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.
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.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-?)
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.
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:
- MAJOR version when you make incompatible API changes, *or a major feature change is introduced*.
- 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,
Naming things is hard.
pgjdbc 13.0 will probably interfere with PostgreSQL 13.0 in a near future.
Believe me or not, but we did have exactly the same discussion a year ago:
The suggestion was "42" as a major version to avoid clash with database version: https://www.postgresql.org/message-id/CAB%3DJe-HraoNEWyNFEUSxGjRpH-gC78jHXvDoxnH%2B0wBe%3Dc1rNg%40mail.gmail.com
Should we make it happen? )
Vladimir
Naming things is hard.
pgjdbc 13.0 will probably interfere with PostgreSQL 13.0 in a near future.
Believe me or not, but we did have exactly the same discussion a year ago:
The suggestion was "42" as a major version to avoid clash with database version: https://www.postgresql.org/message-id/CAB%3DJe-HraoNEWyNFEUSxGjRpH-gC78jHXvDoxnH%2B0wBe%3Dc1rNg%40mail.gmail.com
Should we make it happen? )
Vladimir
We've changed the numbering scheme once already. The goal was to remove the need to release when the server released, and vice-versa.
I don't see any benefit to changing the numbering scheme now. Regardless of the number the answer will be the same. "Use the latest"
I do see a downside to changing it again, which is more confusion.
So my vote is to stay the course. 12xx
On 25 November 2016 at 01:15, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Naming things is hard.pgjdbc 13.0 will probably interfere with PostgreSQL 13.0 in a near future.Believe me or not, but we did have exactly the same discussion a year ago:The suggestion was "42" as a major version to avoid clash with database version: https://www.postgresql.org/message-id/CAB% 3DJe-HraoNEWyNFEUSxGjRpH- gC78jHXvDoxnH%2B0wBe%3Dc1rNg% 40mail.gmail.com Should we make it happen? )Vladimir
>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.
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.
Vladimir
пт, 25 нояб. 2016 г. в 14:52, Dave Cramer <pg@fastcrypt.com>:
We've changed the numbering scheme once already. The goal was to remove the need to release when the server released, and vice-versa.I don't see any benefit to changing the numbering scheme now. Regardless of the number the answer will be the same. "Use the latest"I do see a downside to changing it again, which is more confusion.So my vote is to stay the course. 12xxOn 25 November 2016 at 01:15, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Naming things is hard.pgjdbc 13.0 will probably interfere with PostgreSQL 13.0 in a near future.Believe me or not, but we did have exactly the same discussion a year ago:The suggestion was "42" as a major version to avoid clash with database version: https://www.postgresql.org/message-id/CAB%3DJe-HraoNEWyNFEUSxGjRpH-gC78jHXvDoxnH%2B0wBe%3Dc1rNg%40mail.gmail.comShould we make it happen? )Vladimir
On 25 November 2016 at 07:08, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> 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.
Apologies, scheme was a poor choice of words, We've changed the numbering logic once already
I would agree that it is still common for end-users to confuse 9.4 part with PostgreSQL version.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.
OK,
I could be convinced of this. I'm concerned about the unintended side effects such as packaging guys having to deal with the number changing dramatically.
We've changed the numbering scheme once already. The goal was to remove the need to release when the server released, and vice-versa.
I don't see any benefit to changing the numbering scheme now. Regardless of the number the answer will be the same. "Use the latest"
I do see a downside to changing it again, which is more confusion.
So my vote is to stay the course. 12xx
On 25 November 2016 at 01:15, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Naming things is hard.pgjdbc 13.0 will probably interfere with PostgreSQL 13.0 in a near future.Believe me or not, but we did have exactly the same discussion a year ago:The suggestion was "42" as a major version to avoid clash with database version: https://www.postgresql.org/message-id/CAB% 3DJe-HraoNEWyNFEUSxGjRpH- gC78jHXvDoxnH%2B0wBe%3Dc1rNg% 40mail.gmail.com Should we make it happen? )Vladimir
>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.
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.
Vladimir
пт, 25 нояб. 2016 г. в 14:52, Dave Cramer <pg@fastcrypt.com>:
We've changed the numbering scheme once already. The goal was to remove the need to release when the server released, and vice-versa.I don't see any benefit to changing the numbering scheme now. Regardless of the number the answer will be the same. "Use the latest"I do see a downside to changing it again, which is more confusion.So my vote is to stay the course. 12xxOn 25 November 2016 at 01:15, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:Naming things is hard.pgjdbc 13.0 will probably interfere with PostgreSQL 13.0 in a near future.Believe me or not, but we did have exactly the same discussion a year ago:The suggestion was "42" as a major version to avoid clash with database version: https://www.postgresql.org/message-id/CAB%3DJe-HraoNEWyNFEUSxGjRpH-gC78jHXvDoxnH%2B0wBe%3Dc1rNg%40mail.gmail.comShould we make it happen? )Vladimir
On 25 November 2016 at 07:08, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> 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.
Apologies, scheme was a poor choice of words, We've changed the numbering logic once already
I would agree that it is still common for end-users to confuse 9.4 part with PostgreSQL version.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.
OK,
I could be convinced of this. I'm concerned about the unintended side effects such as packaging guys having to deal with the number changing dramatically.
On Fri, Nov 25, 2016 at 12:15 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Naming things is hard.pgjdbc 13.0 will probably interfere with PostgreSQL 13.0 in a near future.
mmmm, near future, the release frequency of PostgreSQL is mostly once a year, so based on my predictions 10 ->2017, 11 ->2018, 12 ->2019, 13 ->2020. In 4 years from now, I think PgJDBC should have advanced in major version too, probably many times more that PostgreSQL so that in 2020 PgJDBC, who knows, we can be at version 15.0 or 20.0
Believe me or not, but we did have exactly the same discussion a year ago:
Thanks to pointing it. I have read the whole thread but it seems that takes nowhere.
The suggestion was "42" as a major version to avoid clash with database version: https://www.postgresql.org/message-id/CAB% 3DJe-HraoNEWyNFEUSxGjRpH- gC78jHXvDoxnH%2B0wBe%3Dc1rNg% 40mail.gmail.com Should we make it happen? )Vladimir
On Fri, Nov 25, 2016 at 6:12 AM, Dave Cramer <pg@fastcrypt.com> wrote:
I could be convinced of this. I'm concerned about the unintended side effects such as packaging guys having to deal with the number changing dramatically.
There should be no problem since the version is greater than current one, 13 > 9
(or 42 > 9)
so packaging should be no problem...
IMO 42 is a somewhat arbitrary number, and the 13.xx reflects more the continuation of 12xx, and in 4 years until Pg13, we probably should have advanced as few or as many version we can, so a potential clash is more remote.
As you can see, pgjdbc is rather conservative, and there's a good reason for that.
So I do not expect lots of major version changes.
On the other hand, PG might increment major version each year, so I find pgjdbc 13.0 vs pg 13.0 version clash quite real.
Even if we arbitrary advance major version once a year, PG 13.0 would clash with pgjdbc 13.0.
>
There should be no problem since the version is greater than current one, 13 > 9
(or 42 > 9)
so packaging should be no problem...
In theory, there's no difference between theory and practice. In practice, there is.
For instance, some packaging scripts might easily use "9.4" part as a string literal since pgjdbc had "9.4.x" versions for quite a while.
On the other hand, I think 42.0.0 should not create showstopper problems for packagers.
Vladimir
On 25 November 2016 at 11:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
As you can see, pgjdbc is rather conservative, and there's a good reason for that.
Ya, I'm not in favour of change for the sake of change.
So I do not expect lots of major version changes.On the other hand, PG might increment major version each year, so I find pgjdbc 13.0 vs pg 13.0 version clash quite real.
The only thing that would remotely trigger a major version change is a new JDBC version, even then we encapsulate that inside our versions.
Even if we arbitrary advance major version once a year, PG 13.0 would clash with pgjdbc 13.0.>There should be no problem since the version is greater than current one, 13 > 9(or 42 > 9) so packaging should be no problem...In theory, there's no difference between theory and practice. In practice, there is.For instance, some packaging scripts might easily use "9.4" part as a string literal since pgjdbc had "9.4.x" versions for quite a while.On the other hand, I think 42.0.0 should not create showstopper problems for packagers.
I've reached out to the postgres packagers for debian and centos. I'll let you know what they say
On Fri, Nov 25, 2016 at 10:09 AM, Dave Cramer <pg@fastcrypt.com> wrote:
On 25 November 2016 at 11:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:As you can see, pgjdbc is rather conservative, and there's a good reason for that.Ya, I'm not in favour of change for the sake of change.
It's not just for the sake of change, is that people tend to think that current version of 9.4.12xx works only with postgresql 9.4 wich is not true it's very confusing since over the years the scheme was to follow postgres version to declare some kind of support to that version.
So I do not expect lots of major version changes.On the other hand, PG might increment major version each year, so I find pgjdbc 13.0 vs pg 13.0 version clash quite real.The only thing that would remotely trigger a major version change is a new JDBC version, even then we encapsulate that inside our versions.
As I said, there is no need to follow semantic versioning so close, a new feature like support for replication protocol only by itself is a reason to bump the major version.
Break things is also good sometimes, so a @deprecated method can be removed in 2 or 3 major versions. For Java 9 there will be an Enhanced deprecatation (http://openjdk.java.net/jeps/277)... so even for a conservative project, less code means less bugs.
And I'm not saying that we should jump versions like browsers, but currenty "9.4" means nothing, that don't reflect a maven change, a pg9.5 or pg9.6 support, a replication protocol support, etc.
Even if we arbitrary advance major version once a year, PG 13.0 would clash with pgjdbc 13.0.>There should be no problem since the version is greater than current one, 13 > 9(or 42 > 9) so packaging should be no problem...In theory, there's no difference between theory and practice. In practice, there is.For instance, some packaging scripts might easily use "9.4" part as a string literal since pgjdbc had "9.4.x" versions for quite a while.On the other hand, I think 42.0.0 should not create showstopper problems for packagers.
For my part 42.0.0 is fine, it is ultimately your decision, I wish that more contributors, or the community in general have something to say, but it's quiet here.
I've reached out to the postgres packagers for debian and centos. I'll let you know what they say
Great.
On Fri, Nov 25, 2016 at 12:15 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Naming things is hard.pgjdbc 13.0 will probably interfere with PostgreSQL 13.0 in a near future.
mmmm, near future, the release frequency of PostgreSQL is mostly once a year, so based on my predictions 10 ->2017, 11 ->2018, 12 ->2019, 13 ->2020. In 4 years from now, I think PgJDBC should have advanced in major version too, probably many times more that PostgreSQL so that in 2020 PgJDBC, who knows, we can be at version 15.0 or 20.0
Believe me or not, but we did have exactly the same discussion a year ago:
Thanks to pointing it. I have read the whole thread but it seems that takes nowhere.
The suggestion was "42" as a major version to avoid clash with database version: https://www.postgresql.org/message-id/CAB% 3DJe-HraoNEWyNFEUSxGjRpH- gC78jHXvDoxnH%2B0wBe%3Dc1rNg% 40mail.gmail.com Should we make it happen? )Vladimir
On Fri, Nov 25, 2016 at 6:12 AM, Dave Cramer <pg@fastcrypt.com> wrote:
I could be convinced of this. I'm concerned about the unintended side effects such as packaging guys having to deal with the number changing dramatically.
There should be no problem since the version is greater than current one, 13 > 9
(or 42 > 9)
so packaging should be no problem...
IMO 42 is a somewhat arbitrary number, and the 13.xx reflects more the continuation of 12xx, and in 4 years until Pg13, we probably should have advanced as few or as many version we can, so a potential clash is more remote.
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
As you can see, pgjdbc is rather conservative, and there's a good reason for that.
So I do not expect lots of major version changes.
On the other hand, PG might increment major version each year, so I find pgjdbc 13.0 vs pg 13.0 version clash quite real.
Even if we arbitrary advance major version once a year, PG 13.0 would clash with pgjdbc 13.0.
>
There should be no problem since the version is greater than current one, 13 > 9
(or 42 > 9)
so packaging should be no problem...
In theory, there's no difference between theory and practice. In practice, there is.
For instance, some packaging scripts might easily use "9.4" part as a string literal since pgjdbc had "9.4.x" versions for quite a while.
On the other hand, I think 42.0.0 should not create showstopper problems for packagers.
Vladimir
On 25 November 2016 at 11:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
As you can see, pgjdbc is rather conservative, and there's a good reason for that.
Ya, I'm not in favour of change for the sake of change.
So I do not expect lots of major version changes.On the other hand, PG might increment major version each year, so I find pgjdbc 13.0 vs pg 13.0 version clash quite real.
The only thing that would remotely trigger a major version change is a new JDBC version, even then we encapsulate that inside our versions.
Even if we arbitrary advance major version once a year, PG 13.0 would clash with pgjdbc 13.0.>There should be no problem since the version is greater than current one, 13 > 9(or 42 > 9) so packaging should be no problem...In theory, there's no difference between theory and practice. In practice, there is.For instance, some packaging scripts might easily use "9.4" part as a string literal since pgjdbc had "9.4.x" versions for quite a while.On the other hand, I think 42.0.0 should not create showstopper problems for packagers.
I've reached out to the postgres packagers for debian and centos. I'll let you know what they say
On Fri, Nov 25, 2016 at 10:09 AM, Dave Cramer <pg@fastcrypt.com> wrote:
On 25 November 2016 at 11:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:As you can see, pgjdbc is rather conservative, and there's a good reason for that.Ya, I'm not in favour of change for the sake of change.
It's not just for the sake of change, is that people tend to think that current version of 9.4.12xx works only with postgresql 9.4 wich is not true it's very confusing since over the years the scheme was to follow postgres version to declare some kind of support to that version.
So I do not expect lots of major version changes.On the other hand, PG might increment major version each year, so I find pgjdbc 13.0 vs pg 13.0 version clash quite real.The only thing that would remotely trigger a major version change is a new JDBC version, even then we encapsulate that inside our versions.
As I said, there is no need to follow semantic versioning so close, a new feature like support for replication protocol only by itself is a reason to bump the major version.
Break things is also good sometimes, so a @deprecated method can be removed in 2 or 3 major versions. For Java 9 there will be an Enhanced deprecatation (http://openjdk.java.net/jeps/277)... so even for a conservative project, less code means less bugs.
And I'm not saying that we should jump versions like browsers, but currenty "9.4" means nothing, that don't reflect a maven change, a pg9.5 or pg9.6 support, a replication protocol support, etc.
Even if we arbitrary advance major version once a year, PG 13.0 would clash with pgjdbc 13.0.>There should be no problem since the version is greater than current one, 13 > 9(or 42 > 9) so packaging should be no problem...In theory, there's no difference between theory and practice. In practice, there is.For instance, some packaging scripts might easily use "9.4" part as a string literal since pgjdbc had "9.4.x" versions for quite a while.On the other hand, I think 42.0.0 should not create showstopper problems for packagers.
For my part 42.0.0 is fine, it is ultimately your decision, I wish that more contributors, or the community in general have something to say, but it's quiet here.
I've reached out to the postgres packagers for debian and centos. I'll let you know what they say
Great.
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
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...)
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.
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???+1
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.[...]
Vladimir
пт, 25 нояб. 2016 г. в 14:52, Dave Cramer <pg@fastcrypt.com <mailto:pg@fastcrypt.com>>:
Cheers,
Gavin
>I'm in favor of that. Even I, as a packager, almost fail all the times when I
see "9.4" there.
Glad to hear that.
42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.
4.2.0 would indeed be a problem, so the suggestion is 42.0.0
Vladimir
On 27 November 2016 at 08:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>I'm in favor of that. Even I, as a packager, almost fail all the times when Isee "9.4" there.Glad to hear that.I think he did not get we aim for 42.0.0.
I am to blame for that, I misrepresented this.
42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.4.2.0 would indeed be a problem, so the suggestion is 42.0.0
OK, I'm going to post this to hackers with the proposal that we go to 42.0.0
I'm sure that will generate some comments.
Vladimir
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...)
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.
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???+1
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.[...]
Vladimir
пт, 25 нояб. 2016 г. в 14:52, Dave Cramer <pg@fastcrypt.com <mailto:pg@fastcrypt.com>>:
Cheers,
Gavin
On Sun, Nov 27, 2016 at 7:42 AM, Dave Cramer <pg@fastcrypt.com> wrote:
On 27 November 2016 at 08:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:>I'm in favor of that. Even I, as a packager, almost fail all the times when Isee "9.4" there.Glad to hear that.I think he did not get we aim for 42.0.0.I am to blame for that, I misrepresented this.42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.4.2.0 would indeed be a problem, so the suggestion is 42.0.0OK, I'm going to post this to hackers with the proposal that we go to 42.0.0I'm sure that will generate some comments.
+1
>I'm in favor of that. Even I, as a packager, almost fail all the times when I
see "9.4" there.
Glad to hear that.
42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.
4.2.0 would indeed be a problem, so the suggestion is 42.0.0
Vladimir
On 27 November 2016 at 08:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>I'm in favor of that. Even I, as a packager, almost fail all the times when Isee "9.4" there.Glad to hear that.I think he did not get we aim for 42.0.0.
I am to blame for that, I misrepresented this.
42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.4.2.0 would indeed be a problem, so the suggestion is 42.0.0
OK, I'm going to post this to hackers with the proposal that we go to 42.0.0
I'm sure that will generate some comments.
Vladimir
On Sun, Nov 27, 2016 at 7:42 AM, Dave Cramer <pg@fastcrypt.com> wrote:
On 27 November 2016 at 08:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:>I'm in favor of that. Even I, as a packager, almost fail all the times when Isee "9.4" there.Glad to hear that.I think he did not get we aim for 42.0.0.I am to blame for that, I misrepresented this.42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.4.2.0 would indeed be a problem, so the suggestion is 42.0.0OK, I'm going to post this to hackers with the proposal that we go to 42.0.0I'm sure that will generate some comments.
+1
Jorge,
Thanks for bringing this up again. We are going to go ahead with 42.x.x
Any chance you can work on the www site to explain what we are doing and which version people should be using ?
Thanks
On 27 November 2016 at 09:49, Jorge Solórzano <jorsol@gmail.com> wrote:
On Sun, Nov 27, 2016 at 7:42 AM, Dave Cramer <pg@fastcrypt.com> wrote:On 27 November 2016 at 08:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:>I'm in favor of that. Even I, as a packager, almost fail all the times when Isee "9.4" there.Glad to hear that.I think he did not get we aim for 42.0.0.I am to blame for that, I misrepresented this.42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.4.2.0 would indeed be a problem, so the suggestion is 42.0.0OK, I'm going to post this to hackers with the proposal that we go to 42.0.0I'm sure that will generate some comments.+1
Yes, I can work on the www site, but I will need some time.
I guess there is no schedule defined to the 42.0.0 release, maybe late december, early january, or there are intentions to be early december?
I guess there is no schedule defined to the 42.0.0 release, maybe late december, early january, or there are intentions to be early december?
Regards
Jorge
On Mon, Nov 28, 2016 at 10:32 AM, Dave Cramer <pg@fastcrypt.com> wrote:
Jorge,Thanks for bringing this up again. We are going to go ahead with 42.x.xAny chance you can work on the www site to explain what we are doing and which version people should be using ?ThanksOn 27 November 2016 at 09:49, Jorge Solórzano <jorsol@gmail.com> wrote:On Sun, Nov 27, 2016 at 7:42 AM, Dave Cramer <pg@fastcrypt.com> wrote:On 27 November 2016 at 08:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:>I'm in favor of that. Even I, as a packager, almost fail all the times when Isee "9.4" there.Glad to hear that.I think he did not get we aim for 42.0.0.I am to blame for that, I misrepresented this.42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.4.2.0 would indeed be a problem, so the suggestion is 42.0.0OK, I'm going to post this to hackers with the proposal that we go to 42.0.0I'm sure that will generate some comments.+1
>I guess there is no schedule defined to the 42.0.0 release, maybe late december, early january, or there are intentions to be early december?
Technically speaking the aim is to have a month or two between releases.
Well, current milestone has slipped a bit https://github.com/pgjdbc/pgjdbc/milestones, however there are just a couple of issues due.
https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs serverprepared=0" -- needs review
https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to be accessed as .getLob, and .getClob" -- test should be reviewed (e.g. assert messages added)
Vladimir
Jorge,
Thanks for bringing this up again. We are going to go ahead with 42.x.x
Any chance you can work on the www site to explain what we are doing and which version people should be using ?
Thanks
On 27 November 2016 at 09:49, Jorge Solórzano <jorsol@gmail.com> wrote:
On Sun, Nov 27, 2016 at 7:42 AM, Dave Cramer <pg@fastcrypt.com> wrote:On 27 November 2016 at 08:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:>I'm in favor of that. Even I, as a packager, almost fail all the times when Isee "9.4" there.Glad to hear that.I think he did not get we aim for 42.0.0.I am to blame for that, I misrepresented this.42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.4.2.0 would indeed be a problem, so the suggestion is 42.0.0OK, I'm going to post this to hackers with the proposal that we go to 42.0.0I'm sure that will generate some comments.+1
Yes, I can work on the www site, but I will need some time.
I guess there is no schedule defined to the 42.0.0 release, maybe late december, early january, or there are intentions to be early december?
I guess there is no schedule defined to the 42.0.0 release, maybe late december, early january, or there are intentions to be early december?
Regards
Jorge
On Mon, Nov 28, 2016 at 10:32 AM, Dave Cramer <pg@fastcrypt.com> wrote:
Jorge,Thanks for bringing this up again. We are going to go ahead with 42.x.xAny chance you can work on the www site to explain what we are doing and which version people should be using ?ThanksOn 27 November 2016 at 09:49, Jorge Solórzano <jorsol@gmail.com> wrote:On Sun, Nov 27, 2016 at 7:42 AM, Dave Cramer <pg@fastcrypt.com> wrote:On 27 November 2016 at 08:40, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:>I'm in favor of that. Even I, as a packager, almost fail all the times when Isee "9.4" there.Glad to hear that.I think he did not get we aim for 42.0.0.I am to blame for that, I misrepresented this.42.0.0 is greater than 9.4.1212 if compared with maven and/or OSGi rules.4.2.0 would indeed be a problem, so the suggestion is 42.0.0OK, I'm going to post this to hackers with the proposal that we go to 42.0.0I'm sure that will generate some comments.+1
>I guess there is no schedule defined to the 42.0.0 release, maybe late december, early january, or there are intentions to be early december?
Technically speaking the aim is to have a month or two between releases.
Well, current milestone has slipped a bit https://github.com/pgjdbc/pgjdbc/milestones, however there are just a couple of issues due.
https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs serverprepared=0" -- needs review
https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to be accessed as .getLob, and .getClob" -- test should be reviewed (e.g. assert messages added)
Vladimir
In that case I only see 2 options,
a) pospone the release (actual 9.4.1213) until everything is setup to the 42 change.
or b) continue with the actual versioning, and make the change to 42 "when it's ready".
a) pospone the release (actual 9.4.1213) until everything is setup to the 42 change.
or b) continue with the actual versioning, and make the change to 42 "when it's ready".
Jorge
On Mon, Nov 28, 2016 at 10:56 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>I guess there is no schedule defined to the 42.0.0 release, maybe late december, early january, or there are intentions to be early december?
Technically speaking the aim is to have a month or two between releases.Well, current milestone has slipped a bit https://github.com/pgjdbc/pgjdbc/milestones, however there are just a couple of issues due. https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs serverprepared=0" -- needs review https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to be accessed as .getLob, and .getClob" -- test should be reviewed (e.g. assert messages added) Vladimir
I've pushed 42.0.0-SNAPSHOT to the pgjdbc/master.
Vladimir
In that case I only see 2 options,
a) pospone the release (actual 9.4.1213) until everything is setup to the 42 change.
or b) continue with the actual versioning, and make the change to 42 "when it's ready".
a) pospone the release (actual 9.4.1213) until everything is setup to the 42 change.
or b) continue with the actual versioning, and make the change to 42 "when it's ready".
Jorge
On Mon, Nov 28, 2016 at 10:56 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>I guess there is no schedule defined to the 42.0.0 release, maybe late december, early january, or there are intentions to be early december?
Technically speaking the aim is to have a month or two between releases.Well, current milestone has slipped a bit https://github.com/pgjdbc/pgjdbc/milestones, however there are just a couple of issues due. https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs serverprepared=0" -- needs review https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to be accessed as .getLob, and .getClob" -- test should be reviewed (e.g. assert messages added) Vladimir
I've pushed 42.0.0-SNAPSHOT to the pgjdbc/master.
Vladimir
Vladimir wrote:
> Well, current milestone has slipped a bit
> https://github.com/pgjdbc/pgjdbc/milestones, however there are just a
> couple of issues due.
> https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs
> serverprepared=0" -- needs review
> https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to
> be accessed as .getLob, and .getClob" -- test should be reviewed (e.g.
> assert messages added)
I read this as a request for assistance in reviewing these pulls. I looked over the byte[]/Blob part of pull 611 (PgByteaBlob and PgByteaBlobTest) and submitted comments. AbstractBasicLob and PgResultSet changes look good. I did not look over the String/Clob part yet.
Vladimir wrote:
> Well, current milestone has slipped a bit
> https://github.com/pgjdbc/pgjdbc/milestones, however there are just a
> couple of issues due.
> https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs
> serverprepared=0" -- needs review
> https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to
> be accessed as .getLob, and .getClob" -- test should be reviewed (e.g.
> assert messages added)
I read this as a request for assistance in reviewing these pulls. I looked over the byte[]/Blob part of pull 611 (PgByteaBlob and PgByteaBlobTest) and submitted comments. AbstractBasicLob and PgResultSet changes look good. I did not look over the String/Clob part yet.
On 29 November 2016 at 01:19, Brad DeJong <Brad.Dejong@infor.com> wrote:
Vladimir wrote:> Well, current milestone has slipped a bit> https://github.com/pgjdbc/pgjdbc/milestones, however there are just a > couple of issues due.> https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs > serverprepared=0" -- needs review> https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to > be accessed as .getLob, and .getClob" -- test should be reviewed (e.g.> assert messages added)I read this as a request for assistance in reviewing these pulls. I looked over the byte[]/Blob part of pull 611 (PgByteaBlob and PgByteaBlobTest) and submitted comments. AbstractBasicLob and PgResultSet changes look good. I did not look over the String/Clob part yet.
@Brad,
this is great, thanks!
On 29 November 2016 at 01:19, Brad DeJong <Brad.Dejong@infor.com> wrote:
Vladimir wrote:> Well, current milestone has slipped a bit> https://github.com/pgjdbc/pgjdbc/milestones, however there are just a > couple of issues due.> https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs > serverprepared=0" -- needs review> https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to > be accessed as .getLob, and .getClob" -- test should be reviewed (e.g.> assert messages added)I read this as a request for assistance in reviewing these pulls. I looked over the byte[]/Blob part of pull 611 (PgByteaBlob and PgByteaBlobTest) and submitted comments. AbstractBasicLob and PgResultSet changes look good. I did not look over the String/Clob part yet.
@Brad,
this is great, thanks!
Vladimir wrote:
> Well, current milestone has slipped a bit
> https://github.com/pgjdbc/pgjdbc/milestones, however there are just a
> couple of issues due.
> https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs
> serverprepared=0" -- needs review
> https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to
> be accessed as .getLob, and .getClob" -- test should be reviewed (e.g.
> assert messages added)
I just looked at pull 690 and I think the change has unintended side effects. Comment added to the pull.
Vladimir, what do you think about using classifier in pgjdbc? It probably can simplify build of different jar and at the same time have proper versioning in maven.
In maven rules 42.0.0.jre7 > 42.0.0 (jre8) so this should help with correct versioning.
El lun., 28 de nov. de 2016 3:17 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> escribió:
I've pushed 42.0.0-SNAPSHOT to the pgjdbc/master.Vladimir
--
Jorge Solórzano
me.jorsol.com
Vladimir wrote:
> Well, current milestone has slipped a bit
> https://github.com/pgjdbc/pgjdbc/milestones, however there are just a
> couple of issues due.
> https://github.com/pgjdbc/pgjdbc/pull/690 "executeBatch vs
> serverprepared=0" -- needs review
> https://github.com/pgjdbc/pgjdbc/pull/611 "feat: allow byte[] and String to
> be accessed as .getLob, and .getClob" -- test should be reviewed (e.g.
> assert messages added)
I just looked at pull 690 and I think the change has unintended side effects. Comment added to the pull.
Vladimir, what do you think about using classifier in pgjdbc? It probably can simplify build of different jar and at the same time have proper versioning in maven.
In maven rules 42.0.0.jre7 > 42.0.0 (jre8) so this should help with correct versioning.
El lun., 28 de nov. de 2016 3:17 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> escribió:
I've pushed 42.0.0-SNAPSHOT to the pgjdbc/master.Vladimir
--
Jorge Solórzano
me.jorsol.com
Or better yet, simply append .jre8 to the version, that way 42.0.0.jre8 > 42.0.0.jre7 > 42.0.0.jre6 and when Java 9 comes out it will be easy to use .jre9 and there will be no problem to identify what Java version it target.
El mar., 29 de nov. de 2016 10:57 AM, Jorge Solórzano <jorsol@gmail.com> escribió:
Vladimir, what do you think about using classifier in pgjdbc? It probably can simplify build of different jar and at the same time have proper versioning in maven.In maven rules 42.0.0.jre7 > 42.0.0 (jre8) so this should help with correct versioning.El lun., 28 de nov. de 2016 3:17 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> escribió:I've pushed 42.0.0-SNAPSHOT to the pgjdbc/master.Vladimir--Jorge
--
Jorge Solórzano
me.jorsol.com
On 29 November 2016 at 18:54, Jorge Solórzano <jorsol@gmail.com> wrote:
Or better yet, simply append .jre8 to the version, that way 42.0.0.jre8 > 42.0.0.jre7 > 42.0.0.jre6 and when Java 9 comes out it will be easy to use .jre9 and there will be no problem to identify what Java version it target.
Once we go to java 9 we won't need to, it supports versioned jars, we've had this discussion before. http://postgresql.nabble.com/Maven-Artifact-JDK-Suffix-td5881398.html
Dave
Or better yet, simply append .jre8 to the version, that way 42.0.0.jre8 > 42.0.0.jre7 > 42.0.0.jre6 and when Java 9 comes out it will be easy to use .jre9 and there will be no problem to identify what Java version it target.
El mar., 29 de nov. de 2016 10:57 AM, Jorge Solórzano <jorsol@gmail.com> escribió:
Vladimir, what do you think about using classifier in pgjdbc? It probably can simplify build of different jar and at the same time have proper versioning in maven.In maven rules 42.0.0.jre7 > 42.0.0 (jre8) so this should help with correct versioning.El lun., 28 de nov. de 2016 3:17 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> escribió:I've pushed 42.0.0-SNAPSHOT to the pgjdbc/master.Vladimir--Jorge
--
Jorge Solórzano
me.jorsol.com
Good to know Dave, I was not aware about the multi-jar in Java 9.
El mar., 29 de nov. de 2016 7:32 PM, Dave Cramer <pg@fastcrypt.com> escribió:
On 29 November 2016 at 18:54, Jorge Solórzano <jorsol@gmail.com> wrote:Or better yet, simply append .jre8 to the version, that way 42.0.0.jre8 > 42.0.0.jre7 > 42.0.0.jre6 and when Java 9 comes out it will be easy to use .jre9 and there will be no problem to identify what Java version it target.Once we go to java 9 we won't need to, it supports versioned jars, we've had this discussion before. http://postgresql.nabble.com/Maven-Artifact-JDK-Suffix-td5881398.htmlDave
--
Jorge Solórzano
me.jorsol.com
On 29 November 2016 at 18:54, Jorge Solórzano <jorsol@gmail.com> wrote:
Or better yet, simply append .jre8 to the version, that way 42.0.0.jre8 > 42.0.0.jre7 > 42.0.0.jre6 and when Java 9 comes out it will be easy to use .jre9 and there will be no problem to identify what Java version it target.
Once we go to java 9 we won't need to, it supports versioned jars, we've had this discussion before. http://postgresql.nabble.com/Maven-Artifact-JDK-Suffix-td5881398.html
Dave
Good to know Dave, I was not aware about the multi-jar in Java 9.
El mar., 29 de nov. de 2016 7:32 PM, Dave Cramer <pg@fastcrypt.com> escribió:
On 29 November 2016 at 18:54, Jorge Solórzano <jorsol@gmail.com> wrote:Or better yet, simply append .jre8 to the version, that way 42.0.0.jre8 > 42.0.0.jre7 > 42.0.0.jre6 and when Java 9 comes out it will be easy to use .jre9 and there will be no problem to identify what Java version it target.Once we go to java 9 we won't need to, it supports versioned jars, we've had this discussion before. http://postgresql.nabble.com/Maven-Artifact-JDK-Suffix-td5881398.htmlDave
--
Jorge Solórzano
me.jorsol.com