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

From Jorge Solórzano
Subject Re: Versioning policy PgJDBC - discussion
Date
Msg-id CA+cVU8O2KpM1rAYo2C2S6DshR6Cmq6Y_=rxMAxrnrCD4Oxz7zg@mail.gmail.com
Whole thread Raw
In response to Re: Versioning policy PgJDBC - discussion  (Dave Cramer <pg@fastcrypt.com>)
List pgsql-jdbc

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.

 

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