On 4/23/2013 12:43 AM, Knut Anders Hatlen wrote:
Rick Hillegas <[email protected]> writes:
It might be worthwhile to agree on a simple, general policy going
forward, something like this:
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 I think we can hit. Let's call this
the CURRENT version.
ii) CURRENT - 1
iii) CURRENT - 2
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.
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 and CDC.
III) Removing the JDBC 3 version of the public api.
Thanks, Rick. I think this sounds like a good rule of thumb. Judging by
how back-porting to older branches has happened up till now, the 10.10
branch is going to be alive and receive fixes for quite some time, so
those who run Derby on these old platforms won't lose access to bug
fixes anytime soon.
The idea that bug fixes will continue to backport is great, but how easy
will it be to continue to backport
fixes. Is it likely as soon as we approve this that code will be
changed in ways that will make it much harder to backport? What exact
kind of changes are being considered if the proposal is adopted?
I currently support a lot of customers using older releases, actually
all the way back to 10.1. With this
change is there any "rule of thumb" that can be used to understand if a
code change in trunk can be backported to a previous version. I can
see us agreeing on this, and then a mass rototil happen changing the
code to use a new java feature making it much harder to backport fixes.
I have liked the ad-hoc rule of thumb that new features have used
new features, and made appropriate build changes for them.
I don't expect us to support java versions forever, but would like to
be conservative in changing existing code.
Of course I could work exclusively in an old branch, but would prefer
to work off of trunk if it works with the community.
