Postgres Pro
Downloads
Home   >   mailing lists

Thread: Version question

Version question

From
"Campbell, Lance"
Date:

Thanks for all of the great work on developing the JDBC drivers for PostgreSQL.

 

I noticed that on the JDBC Driver download page the newest major version is 9.4 .  I thought in the past that when a newer major version of PostgreSQL is released there is a corresponding major version released of the JDBC driver.  I have been watch for a 9.5 release.  Is there traditionally a matching version between PostgreSQL and JDBC?  Or am I wrong.  Maybe they do not go hand in hand.  I am just checking.

 

Thanks,

 

Lance Campbell

Web Services

University of Illinois  

 

Re: Version question

From
Dave Cramer
Date:
Hi Lance,

You are correct, historically they have. While there may have been a good reason before, there is not one now other than confusion. I'd really like to break the cycle. 

Just use the latest version on 9.5, it will work fine


On 14 March 2016 at 09:24, Campbell, Lance <lance@illinois.edu> wrote:

Thanks for all of the great work on developing the JDBC drivers for PostgreSQL.

 

I noticed that on the JDBC Driver download page the newest major version is 9.4 .  I thought in the past that when a newer major version of PostgreSQL is released there is a corresponding major version released of the JDBC driver.  I have been watch for a 9.5 release.  Is there traditionally a matching version between PostgreSQL and JDBC?  Or am I wrong.  Maybe they do not go hand in hand.  I am just checking.

 

Thanks,

 

Lance Campbell

Web Services

University of Illinois  

 


Re: Version question

From
"Campbell, Lance"
Date:

Thanks for the info.  I thought it was just me.  I would actually throw out the idea of keeping them in sync is actually nice.  It is a way for users to have a little more confidence that they are in sync.  It drives me crazy every time the Tomcat Apache group upgrades to a major release.  Their numbers are always one off of the Java JVM the versions are built on. 

 

It may seem trivial but when you develop software it is kind of nice to have version numbers that match up to the things they are most associated with.  Just a thought to throw out there. 

 

Either way is fine with me.  I am just thankful for the hard work everyone does on the JDBC driver.  It is nice to know open source software like this can be used and trusted in a production environment.  No matter what the version numbering format happens to be.

 

Lance

 

From: davecramer@gmail.com [mailto:davecramer@gmail.com] On Behalf Of Dave Cramer
Sent: Monday, March 14, 2016 8:28 AM
To: Campbell, Lance <lance@illinois.edu>
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Version question

 

Hi Lance,

 

You are correct, historically they have. While there may have been a good reason before, there is not one now other than confusion. I'd really like to break the cycle. 

 

Just use the latest version on 9.5, it will work fine


 

On 14 March 2016 at 09:24, Campbell, Lance <lance@illinois.edu> wrote:

Thanks for all of the great work on developing the JDBC drivers for PostgreSQL.

 

I noticed that on the JDBC Driver download page the newest major version is 9.4 .  I thought in the past that when a newer major version of PostgreSQL is released there is a corresponding major version released of the JDBC driver.  I have been watch for a 9.5 release.  Is there traditionally a matching version between PostgreSQL and JDBC?  Or am I wrong.  Maybe they do not go hand in hand.  I am just checking.

 

Thanks,

 

Lance Campbell

Web Services

University of Illinois  

 

 

Re: Version question

From
Vladimir Sitnikov
Date:
Well, what if we indeed release 9.5.x just to note that "it is at
least helloworld-compatible with backend 9.5"?

I guess as long as pgjdbc's versions are "close" to backend's
versions, users would be confused if those are compatible.
So it looks we either have to release pgjdbc 9.5.x, or release
something like 42.x.y

Any thoughts?

Vladimir

Re: Version question

From
Dave Cramer
Date:
My thoughts:

releasing 9.5 is the path of least resistance.
Ideally we announce that we are going to release version 42.x.y. however nobody will pay attention until their build breaks.
Then we will get a flood of messages implying that we broke their build.

My gut says to go with 42.x.y, my head says it will be easier to take the easy way out and release 9.5.x




On 14 March 2016 at 10:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Well, what if we indeed release 9.5.x just to note that "it is at
least helloworld-compatible with backend 9.5"?

I guess as long as pgjdbc's versions are "close" to backend's
versions, users would be confused if those are compatible.
So it looks we either have to release pgjdbc 9.5.x, or release
something like 42.x.y

Any thoughts?

Vladimir

Re: Version question

From
Christopher BROWN
Date:
Hello,

I would recommend aligning with database versioning scheme (so 9.5.x) ; it would have been clearer from the start if the version numbers had never been close, but any change now seems arbitrary and confusing (even if I prefer semantic versioning in general).

Regarding semantic versioning, the "major" component here is the JDBC API, so you can probably disregard A.B -- as in 9.5 -- as a marker saying "we've tried it with that version, and it works".  Then, even if it's not fully compliant with proper semantic versioning, use the C (of A.B.C) as a marker for feature changes, and the trailing qualifier for patches.

For example:

9.4.C.D => any version tested with 9.4.x (backend)
9.5.C.D => tested with 9.5
9.5.1.000 => first build approved for 9.5 backend
9.5.2.000 => like 9.5.1.0 but with feature changes (new packaging, new properties, new capabilities, etc)
9.5.1.001 => like 9.5.1.0 but with bugfixes (with no new features)

The prefixed zeros for "D" enable alphanumerical sorting (with OSGi Version objects, for example), and I personally find it more usable (readable) than 20160314 for example (even if that sorts too ; it doesn't look like a nightly snapshot tag).  And I imagine there'll still be -jre6, -jre7, -jre8 variants to distinguish API target versions.

Hope that helps,
Christopher



On 14 March 2016 at 15:14, Dave Cramer <pg@fastcrypt.com> wrote:
My thoughts:

releasing 9.5 is the path of least resistance.
Ideally we announce that we are going to release version 42.x.y. however nobody will pay attention until their build breaks.
Then we will get a flood of messages implying that we broke their build.

My gut says to go with 42.x.y, my head says it will be easier to take the easy way out and release 9.5.x




On 14 March 2016 at 10:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Well, what if we indeed release 9.5.x just to note that "it is at
least helloworld-compatible with backend 9.5"?

I guess as long as pgjdbc's versions are "close" to backend's
versions, users would be confused if those are compatible.
So it looks we either have to release pgjdbc 9.5.x, or release
something like 42.x.y

Any thoughts?

Vladimir


Re: Version question

From
Dave Cramer
Date:
Hi Lance,

You are correct, historically they have. While there may have been a good reason before, there is not one now other than confusion. I'd really like to break the cycle. 

Just use the latest version on 9.5, it will work fine


On 14 March 2016 at 09:24, Campbell, Lance <lance@illinois.edu> wrote:

Thanks for all of the great work on developing the JDBC drivers for PostgreSQL.

 

I noticed that on the JDBC Driver download page the newest major version is 9.4 .  I thought in the past that when a newer major version of PostgreSQL is released there is a corresponding major version released of the JDBC driver.  I have been watch for a 9.5 release.  Is there traditionally a matching version between PostgreSQL and JDBC?  Or am I wrong.  Maybe they do not go hand in hand.  I am just checking.

 

Thanks,

 

Lance Campbell

Web Services

University of Illinois  

 


Re: Version question

From
"Campbell, Lance"
Date:

Thanks for the info.  I thought it was just me.  I would actually throw out the idea of keeping them in sync is actually nice.  It is a way for users to have a little more confidence that they are in sync.  It drives me crazy every time the Tomcat Apache group upgrades to a major release.  Their numbers are always one off of the Java JVM the versions are built on. 

 

It may seem trivial but when you develop software it is kind of nice to have version numbers that match up to the things they are most associated with.  Just a thought to throw out there. 

 

Either way is fine with me.  I am just thankful for the hard work everyone does on the JDBC driver.  It is nice to know open source software like this can be used and trusted in a production environment.  No matter what the version numbering format happens to be.

 

Lance

 

From: davecramer@gmail.com [mailto:davecramer@gmail.com] On Behalf Of Dave Cramer
Sent: Monday, March 14, 2016 8:28 AM
To: Campbell, Lance <lance@illinois.edu>
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Version question

 

Hi Lance,

 

You are correct, historically they have. While there may have been a good reason before, there is not one now other than confusion. I'd really like to break the cycle. 

 

Just use the latest version on 9.5, it will work fine


 

On 14 March 2016 at 09:24, Campbell, Lance <lance@illinois.edu> wrote:

Thanks for all of the great work on developing the JDBC drivers for PostgreSQL.

 

I noticed that on the JDBC Driver download page the newest major version is 9.4 .  I thought in the past that when a newer major version of PostgreSQL is released there is a corresponding major version released of the JDBC driver.  I have been watch for a 9.5 release.  Is there traditionally a matching version between PostgreSQL and JDBC?  Or am I wrong.  Maybe they do not go hand in hand.  I am just checking.

 

Thanks,

 

Lance Campbell

Web Services

University of Illinois  

 

 

Re: Version question

From
Vladimir Sitnikov
Date:
Well, what if we indeed release 9.5.x just to note that "it is at
least helloworld-compatible with backend 9.5"?

I guess as long as pgjdbc's versions are "close" to backend's
versions, users would be confused if those are compatible.
So it looks we either have to release pgjdbc 9.5.x, or release
something like 42.x.y

Any thoughts?

Vladimir

Re: Version question

From
Dave Cramer
Date:
My thoughts:

releasing 9.5 is the path of least resistance.
Ideally we announce that we are going to release version 42.x.y. however nobody will pay attention until their build breaks.
Then we will get a flood of messages implying that we broke their build.

My gut says to go with 42.x.y, my head says it will be easier to take the easy way out and release 9.5.x




On 14 March 2016 at 10:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Well, what if we indeed release 9.5.x just to note that "it is at
least helloworld-compatible with backend 9.5"?

I guess as long as pgjdbc's versions are "close" to backend's
versions, users would be confused if those are compatible.
So it looks we either have to release pgjdbc 9.5.x, or release
something like 42.x.y

Any thoughts?

Vladimir

Re: Version question

From
Christopher BROWN
Date:
Hello,

I would recommend aligning with database versioning scheme (so 9.5.x) ; it would have been clearer from the start if the version numbers had never been close, but any change now seems arbitrary and confusing (even if I prefer semantic versioning in general).

Regarding semantic versioning, the "major" component here is the JDBC API, so you can probably disregard A.B -- as in 9.5 -- as a marker saying "we've tried it with that version, and it works".  Then, even if it's not fully compliant with proper semantic versioning, use the C (of A.B.C) as a marker for feature changes, and the trailing qualifier for patches.

For example:

9.4.C.D => any version tested with 9.4.x (backend)
9.5.C.D => tested with 9.5
9.5.1.000 => first build approved for 9.5 backend
9.5.2.000 => like 9.5.1.0 but with feature changes (new packaging, new properties, new capabilities, etc)
9.5.1.001 => like 9.5.1.0 but with bugfixes (with no new features)

The prefixed zeros for "D" enable alphanumerical sorting (with OSGi Version objects, for example), and I personally find it more usable (readable) than 20160314 for example (even if that sorts too ; it doesn't look like a nightly snapshot tag).  And I imagine there'll still be -jre6, -jre7, -jre8 variants to distinguish API target versions.

Hope that helps,
Christopher



On 14 March 2016 at 15:14, Dave Cramer <pg@fastcrypt.com> wrote:
My thoughts:

releasing 9.5 is the path of least resistance.
Ideally we announce that we are going to release version 42.x.y. however nobody will pay attention until their build breaks.
Then we will get a flood of messages implying that we broke their build.

My gut says to go with 42.x.y, my head says it will be easier to take the easy way out and release 9.5.x




On 14 March 2016 at 10:05, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
Well, what if we indeed release 9.5.x just to note that "it is at
least helloworld-compatible with backend 9.5"?

I guess as long as pgjdbc's versions are "close" to backend's
versions, users would be confused if those are compatible.
So it looks we either have to release pgjdbc 9.5.x, or release
something like 42.x.y

Any thoughts?

Vladimir