[Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0

From: thomas at tada(dot)se (Thomas Hallgren)
To:
Subject: [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0
Date: 2010-10-11 18:09:44
Message-ID: 4CB352E8.8090700@tada.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

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

In response to

Responses

Browse pljava-dev by date

  From Date Subject
Next Message JOSE CARLOS MARTINEZ LLARIO 2010-10-13 10:25:22 [Pljava-dev] congratulations about the next release
Previous Message Johann 'Myrkraverk' Oskarsson 2010-10-11 16:58:48 [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0