agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feedSubject: [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0
Date: Mon, 11 Oct 2010 20:09:44 +0200
Message-ID: <4CB352E8.8090700@tada.se> (raw)
In-Reply-To: <AANLkTiko8_mJYxiATsWtr3M2UXhshYKNbpTNivnk1NpV@mail.gmail.com>
References: <AANLkTiko8_mJYxiATsWtr3M2UXhshYKNbpTNivnk1NpV@mail.gmail.com>
On 10/11/2010 06:58 PM, Johann 'Myrkraverk' Oskarsson wrote:
> On Mon, Oct 11, 2010 at 3:48 AM, Kris Jurka<books at ejurka.com> wrote:
>
>>
>> On Fri, 8 Oct 2010, Johann 'Myrkraverk' Oskarsson wrote:
>>
>>
>>> If there are no compile errors for PostgreSQL 8.4 and 9.0 with and
>>> without GCJ, 1.4.1 will be released as source Friday 29th of October
>>> 2010 by me.
>>>
>>
I'm not a big fan of continuing new ports with retained compatibility
for Java 5/GCJ. Seems to me it's a lot of work for no return. Who needs
that? Why can't they just shift to Java 6 or stay put with an older
version of PL/Java? Or, if they really need a Java 5 port, compile it
themselves?
>> I think a release that changes support from JDBC3 -> JDBC4 should be a major
>> release (that is 1.5), not 1.4.1 which seems like a minor change. Someone
>> running a server that uses a 1.4 or 1.5 JVM will be taken by surprise if
>> they try upgrading from 1.4 to 1.4.1.
>>
> I am mostly adding new interfaces and rarely change existing code. An
> exception would be something like todays commit.
>
> I am using
> JAVAC := javac -source 1.6 -target 1.6
> in src/java/Makefile.global and it fails to compile with Java 5 and 4.
> I intend to commit this change when it compiles with Java 6.
>
> Binaries should therefore be clearly marked Java 6, such as having
> java6 in their name.
>
>
If we are changing API, then we should bump the major version. I.e.
breaking current API means go to 2.0.0
If we are making new additions in functionality while retaining backward
compatibility, then bump minor, i.e. 1.5.0
Bumping the bugfix (or micro) number limits the addition to mere bugfixes.
IMO, changing from JDBC 3 to 4 is indeed a breaking API change and calls
for a new major version of PL/Java, so when that happens, we must go to
2.0.0, not 1.5.0.
Adding interfaces while still retaining backward compatibility sounds
like a minor version bump, i.e. 1.5.0.
What I've said so far only relates to the actual version of the PL/Java
source. Naming the various pre-compiled binaries is separate from that.
I think that whatever is mainstream (i.e. Java >= 1.6) should typically
not have the java version included in the name. Special ports for 1.5 or
GCJ etc. should be the ones that get tagged.
I think the term 'gnu' in the name is somewhat redundant. Perhaps we can
use names like:
pljava-1.5.0-pg8.4-linux-x86_64.tar.gz
pljava-1.5.0-pg8.4-linux-x86.tar.gz
pljava-1.5.0-pg8.4-windows-x86.tar.gz
pljava-1.5.0-pg8.4-windows-x86-gcj5.tar.gz
pljava-2.0.0-pg9.0-linux-x86_64.tar.gz
...
I made an attempt to put things in order of importance to make it easier
to read.
Regards,
Thomas Hallgren
view thread (4+ messages) latest in thread
Message-ID: <4CB352E8.8090700@tada.se>
Permalink: ../4CB352E8.8090700@tada.se/
Also on: postgresql.org/message-id/4CB352E8.8090700@tada.se
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pljava-dev@postgresql.org
Subject: Re: [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0
In-Reply-To: <4CB352E8.8090700@tada.se>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox