Re: Versioning policy PgJDBC - discussion

From: Jorge Solórzano <jorsol(at)gmail(dot)com>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Versioning policy PgJDBC - discussion
Date: 2016-11-25 16:57:41
Message-ID: CA+cVU8O2KpM1rAYo2C2S6DshR6Cmq6Y_=rxMAxrnrCD4Oxz7zg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On Fri, Nov 25, 2016 at 10:09 AM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:

>
> On 25 November 2016 at 11:05, Vladimir Sitnikov <
> sitnikov(dot)vladimir(at)gmail(dot)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.

>
> Dave Cramer
>
> davec(at)postgresintl(dot)com
> www.postgresintl.com
>
>
>

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Gavin Flower 2016-11-25 19:02:40 Re: Versioning policy PgJDBC - discussion
Previous Message Dave Cramer 2016-11-25 16:09:35 Re: Versioning policy PgJDBC - discussion