Re: SQLJSON

Sorry, maybe I'm misunderstanding:  my complaint is that if the PG driver packages
version 1.0, but I use a feature added in a hypothetical 1.1, then the 1.0 bundled in
PG becomes a problem for me.

So what I am talking about is *forward* compatibility, not backward.

I'm not claiming this is a huge issue, I just wanted to point out that these
interfaces can and do evolve, so it is a false assumption that the version
baked into the PG driver will be good for all time.


On Jun 30, 2015, at 1:04 PM, Markus KARG <markus@headcrashing.eu> wrote:

> Being a JAX-RS EG member I need to chime in here: JAX-RS actually is fully
> backwards compatible, fully intentionally. We will never break any existing
> feature, and I think I am speaking for hardly every JSR EG when I say that
> most (if not all) JSR standards are always backwards compatible. The 22
> different versions actually are no releases but development milestones not
> intended for productive use.
>
> All parts of Java EE have a restriction that nothing may break backwards
> compatibility ever. This not only is true of JAX-RS but most certainly also
> JSON-P and JSON-B. It is a guarantee the Java EE spec lead (Bill Shannon)
> gives for all parts of the Java EE platform. So we can really safely rely on
> that.
>
> -Markus
>
> On Jun 30, 2015, at 10:25 AM, Álvaro Hernández Tortosa <aht@8Kdata.com>
> wrote:
>
>>
>>   Thanks for asking for the double-check. No, indeed I'm still asking to
> provide the class files for the API in the package. I feel that's the right
> way, and I don't see it would create conflicts unless JSR353 would create a
> new version, something which I believe extremely unlikely until it merges
> with Java10 or JDBC5 comes out, point at which we would need to change
> things anyway.
>
> I do not believe this is as unlikely as you think.  For example, the
> javax.ws.rs JAX-RS spec has 22 different versions available on Maven
> Central.  Granted, many of these are milestone builds and not releases, but
> there are already two major versions, a patch available and a new minor
> version coming through the pipes.
>
> So assuming these spec jars will not change is provably false.  One of my
> fears is that if PG bundles JSR353 1.0, and I need JSR353 1.0.1, I now need
> to fight the driver packaging to upgrade a theoretically unrelated package.
>
>>
>>   However, I don't want to insist more or suck more dev bandwitch, that's
> my opinion and it's been stated more times than I wish, so I would now leave
> the decision to the rest of you :)
>>
>>   Regards,
>>
>>   Alvaro
>>
>>
>> --
>> Álvaro Hernández Tortosa
>>
>>
>> -----------
>> 8Kdata
>>
>>
>>
>> On 30/06/15 18:49, Vladimir Sitnikov wrote:
>>> ah. I meant to double-check with Álvaro if he is suggesting compile
>>> type dependency.
>>>
>>> If he means that we in fact are discussing the same thing, so no
>>> contradiction exists.
>>>
>>>> However, regarding POLA you say "compile dependency" which means you
>>>> suggest _not_ including javax.json into pgjdbc.jar
>>>>
>>>> Álvaro , Can you please tell us if "using compile type dependency for
> both
>>>> javax.json and RI" suits you?
>>>>
>>> Vladimir
>>
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc