Re: Maven Artifact JDK Suffix

From: Sehrope Sarkuni <sehrope(at)jackdb(dot)com>
To: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Mark Rotteveel <mark(at)lawinegevaar(dot)nl>, Dave Cramer <davecramer(at)gmail(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Maven Artifact JDK Suffix
Date: 2016-01-13 02:58:28
Message-ID: CAH7T-ap9d+UJiERNrJdP2Lbt1bJPWfnfJqTc9mu8s7kcqPpj3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On Mon, Jan 11, 2016 at 4:22 AM, Vladimir Sitnikov <
sitnikov(dot)vladimir(at)gmail(dot)com> wrote:

> >What if I am on the latest jre8 version when Java 9 is out, and I need to
> go
> >back to an earlier version: then I need to track when the switch from
> >unsuffixed Java 8 to suffixed Java 8 version occurred to be able to
> >downgrade (granted, that is a bit less common scenario).
>
> Frankly speaking, I do not get the use-case you are trying to convey.
>
> Suppose you have x.y.z and that is the latest jre8 version at some
> point in time.
> Even after jre9 is launched, the same x.y.z will still be jre8.
>
> So if you "do not want to upgrade", you just keep your version x.y.z.
>
> If you want to upgrade (suppose, the most current version is "k.l.m"),
> you just use k.l.m-jre8 if you a still stuck with jre8.
>
> > What if I am on the latest jre8 version when Java 9 is out, and I need
> to go
> > back to an earlier version
>
> As I said above, I see no practical use case, except for some "bug
> hunting via driver version bisection".
> If that is the case, there is always list of all the versions:
> https://jdbc.postgresql.org/download.html#others
>

This would definitely come back to bite somebody. I can imagine a user
upgrading their driver version (say to get a fix in a newer version) but
not realize that the newer version requires a newer JDK. Many users won't
read any release notes at all; they'll just see there's a newer driver
available in Maven central and update to it. It's surprising behavior to
suddenly require a new JDK and that would be avoided with explicitly
suffixed versions.

Thinking about this a bit more, maybe version numbers aren't what we should
be suffixing. Code-wise it's true that the JDK 8 driver is a super set of
the JDK 7 one (which is a super set of the JDK 6 one). But the output JARs
are not really different versions of the same thing. They're entirely
different artifacts. The suffix should be on the Maven artifactId (not the
version).

Changing the suffixes to be on the artifactId would also play nice with
Maven version ranges[1]. Otherwise the suffix on the end of the version
number leads to a weird situation where a higher versioned JDK 7 driver can
be considered "newer" than an older version of a JDK 8 driver[2]. Sure
there will most likely be a newer JDK 8 release as well but it's still odd
and can be avoided with better naming.

I'm thinking something like this:

<!-- JDK 8 -->
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql-jre8</artifactId>
<version>9.4.1207</version>
</dependency>

<!-- JDK 7 -->
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql-jre7</artifactId>
<version>9.4.1207</version>
</dependency>

<!-- JDK 6 -->
<dependency>
<groupId>org.postgresql</groupId>
<artifactId>postgresql-jre6</artifactId>
<version>9.4.1207</version>
</dependency>

Thoughts?

[1]: https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html
[2]: 9.4.1210.jre7 > 9.4.1207.jre8 per

Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Vladimir Sitnikov 2016-01-13 10:44:31 Re: Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102
Previous Message C A M E X T E R I O R - INDUSTRIA - COMERCIO 2016-01-13 00:01:35 Exporte a Marruecos - Mision Comercial 25 Enero 2016