Lists: | PostgreSQL : PostgreSQL 메일 링리스트 : 2010-10-13 년부터 토토 커뮤니티Dev 17:43 |
---|
From: | johann at myrkraverk(dot)com (Johann 'Myrkraverk' Oskarsson) |
---|---|
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 16:58:48 |
Message-ID: | AANLkTiko8_mJYxiATsWtr3M2UXhshYKNbpTNivnk1NpV@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pljava-dev |
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 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.
So far, nothing I've done will affect existing code. If you still
think this warrants a version number like 1.5, I'll be fine with it.
>> I may or may not release binaries. ?If I do they will lag behind a day or
>> more.
>>
>
> I think it's important to release windows binaries. ?Building extensions on
> windows is a real pain, so to get any traction with the release, I think we
> need binaries. ?Releasing linux binaries is pretty easy, so I don't see a
> reason not to do it.
I, personally, will not make any effort at releasing binaries until
November 1st at the earliest.
Johann
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 |
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
From: | johann at myrkraverk(dot)com (Johann 'Myrkraverk' Oskarsson) |
---|---|
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-13 17:43:38 |
Message-ID: | AANLkTikwE5Z-nY5CStidPtryEH5UcD9f=qv8YQJZLrbB@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | PostgreSQL : PostgreSQL 메일 링리스트 : 2010-10-13 년부터 토토 커뮤니티Dev 17:43 |
Dear pljava-dev,
Just to inform you that even though there was no commit yesterday, the
schedule still holds.
Johann