agora inbox for pljava-dev@postgresql.orghelp / color / mirror / Atom feed
[Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0 4+ messages / 0 participants [nested] [flat]
* [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0 @ 2010-10-08 15:03 0 siblings, 0 replies; 4+ messages in thread From: @ 2010-10-08 15:03 UTC (permalink / raw) Of course I meant the 29th... Johann ^ permalink raw reply [nested|flat] 4+ messages in thread
* [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0 @ 2010-10-11 16:58 0 siblings, 1 reply; 4+ messages in thread From: @ 2010-10-11 16:58 UTC (permalink / raw) 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 ^ permalink raw reply [nested|flat] 4+ messages in thread
* [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0 @ 2010-10-11 18:09 parent: 0 siblings, 1 reply; 4+ messages in thread From: @ 2010-10-11 18:09 UTC (permalink / raw) 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 ^ permalink raw reply [nested|flat] 4+ messages in thread
* [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0 @ 2010-10-13 17:43 parent: 0 siblings, 0 replies; 4+ messages in thread From: @ 2010-10-13 17:43 UTC (permalink / raw) Dear pljava-dev, Just to inform you that even though there was no commit yesterday, the schedule still holds. Johann ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2010-10-13 17:43 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2010-10-08 15:03 [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0 2010-10-11 16:58 [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0 2010-10-11 18:09 ` 2010-10-13 17:43 `
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox