From: thomas at tada.se (Thomas Hallgren) Date: Mon, 11 Oct 2010 20:09:44 +0200 Subject: [Pljava-dev] 1.4.1 Release Schedule: Friday 29th of October with Java 6 & PostgreSQL 8.4 and 9.0 In-Reply-To: References: Message-ID: <4CB352E8.8090700@tada.se> On 10/11/2010 06:58 PM, Johann 'Myrkraverk' Oskarsson wrote: > On Mon, Oct 11, 2010 at 3:48 AM, Kris Jurka 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