Re: RFC Changing the version number for JDBC

From: Dave Cramer <davecramer(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC Changing the version number for JDBC
Date: 2016-11-27 19:47:04
Message-ID: CADK3HHLB8CmNh4gXmzv7N31FKaqEWd3Oc0rDcKWZMmhJiZUEGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 November 2016 at 11:29, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dave Cramer <davecramer(at)gmail(dot)com> writes:
> > We are proposing changing the JDBC version from
> > 9.4.xxxx to 42.x.x
>
> > We have two issues we are trying to address here.
>
> > 1) we do not want to be tied to the server release schedule. This has
> been
> > somewhat addressed already but has left us with the second issue.
>
> > 2) Avoid confusion as to which version to use with which server version.
> > Currently the naming scheme has 9.4 in it which leads people to believe
> it
> > is for server version 9.4
>
> To clarify --- are you planning to advance the "42" part fairly often,
> or is it intended to stay static? If the latter, I think this design
> is shortsighted. Given current project policies, server version 42
> should come out in 2049, plus or minus a bit, and you'd be right back
> with the is-this-meant-to-match-the-server-version problem.
>
> Admittedly, many of us won't be around in 2049, but it's not out of
> the realm of possibility that the project would still be kicking.
>
> If you advance the major version part every year or so, it'd be OK
> since you could expect to stay well ahead of the server's major
> version number forever.
>

Ya we could easily stay ahead of the server.

Thanks,

Dave Cramer

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-11-27 19:50:33 Re: User-defined Operator Pushdown and Collations
Previous Message Paul Ramsey 2016-11-27 19:15:20 Re: User-defined Operator Pushdown and Collations