On 4/26/13 10:13 AM, Katherine Marsden wrote:
On 4/26/2013 6:39 AM, Rick Hillegas wrote:
Thanks to everyone for working through the implications of this proposed change. I'd like to summarize the discussion so far by revamping the proposal as follows:

A) We expect that a new feature release (branch) will support the following Java versions:

i) The current version being developed by the Open JDK community. This is a stretch goal but one which we think we can hit. Let's call this the CURRENT version.

ii) CURRENT - 1
If I understand the definition of CURRENT that would be java 8, so CURRENT - 2 would be java 6 which I think is still absolutely required and the current plan for 10.11.

I feel strongly that we should discuss dropping java version support *as* we drop it and not rely on a general policy like this moving forward.


B) We expect that maintenance releases on a branch will continue to support the same Java versions as the initial feature release cut from that branch.

C) Developers will need to keep in mind the porting implications of using modern JVM features in code which may need to be reworked to run on older JVMs.

Adopting this policy would result in the following changes to the 10.11 trunk:

I) Removing build support for Java 5 and CDC.

II) Purging user doc references to Java 5, CDC, and the JDBC 4 DataSources.

III) Removing the JDBC 4 version of the public api from the published javadoc. The recently introduced CP2 DataSources would need to migrate to the JDBC 3 version of the published javadoc. The JDBC 4 versions of the DataSources would still exist, but they would be vacuous extensions of their JDBC 3 counterparts.

These particular changes moving forward for 10.11 trunk seem ok to me. Perhaps a vote would be good.
Thanks, Kathey. Here's my plan:

o Continue collecting responses to this proposal and incorporate them into a revised proposal (including the feedback you gave above).

o Repeat this process until the proposal stabilizes.

o Then call a vote.

Thanks,
-Rick

Thanks,
-Rick





Reply via email to