Hi, all. I haven't gotten any more comments on the proposal at
http://wiki.apache.org/db-derby/ModuleVersioningGuidelines, so I'm going
to update this page based on the comments I have received so far and
then we'll try for another vote.
Thanks,
David
David W. Van Couvering wrote:
So, I'll wait for another overnight (over-day) period, but it sounds
like we may have a level of consensus here (fingers crossed).
What I propose to do is take Jeremy's quick brain dump (thanks again for
doing this Jeremy) and turn it into a more complete policy around this.
Hopefully I'll capture the essence of this correctly, but I'm sure
you'll correct me if I miss something :)
I'll put this on the Derby Wiki, to make it more readable/reviewable.
Thanks all,
David
Jeremy Boynes wrote:
Daniel John Debrunner wrote:
Jeremy Boynes wrote:
Think of the carnage if it was java_14208_b13.sql_300.Connection
It's actually instructive to look how Java solves this:
- The interface is kept upwards compatible, by following rules such as
only new methods/fields etc.
Then to look at how a consumer, Derby, deals with the fact of multiple
versions of the interface:
- Derby only provides and uses the functionality to match the version of
the interface (java.sql.Connection) loaded, determined at runtime.
I'd thought this was a workable direction being proposed about six
thousand message ago, upwards compatible apis and the ability for a
consumer to handle a lower version. Not sure what derailed it.
Kathey asked if I would be willing to write something up and I started
thinking about it but haven't had the bandwidth to write anything.
As a quick braindump:
* there are rules that restrict changes to the interface going forward
* Sun (et al) stick to those rules even when it is painful
* no class/method is removed without being deprecated first
* the JVM supports version skew a little by not requiring an
implementation to implement all methods in a interface (at runtime)
* the interfaces often provide a mechanism to determine what features of
an API the implementation implements
* frameworks can utilize multiple classloaders to load multiple versions
of a class into the VM - tools have developed to simplify this
I think we can support a scenario where:
* a comsumer expecting version X.Y will work with any implementation
X.Y' when Y' >= Y
* a consumer expecting X.Y will work with X.Y' when Y' < Y by version
detection and degraded functionality (Y' level). If Y level function
is required then it will gracefully die (able to detect rather
than AbstractMethodError)
* X.Y defines the interface version, i.e. X.Y.Z works with X.Y.Z' for
all Z'
* X defines the compatibility level i.e. X and X' are not guaranteed
to work together (although we will try to ensure they do)
Basic rules:
* at the Z level, no API change is allowed, just implementation changes
* at the Y level, additive API changes are allowed but must be
accompanied by support in the versioning mechanism so that they can be
detected. Things can be deprecated
* at the Z level, incompatible changes are allowed. Items deprecated in
version X can be removed in version X+2 (implicitly (X+2).0.0).
This all applies to operation in a single classloader. Where multiple
classloaders are involved (inside one VM or in multiple VMs) a
different set of versioning behaviours applies to the wire protocol.
--
Jeremy
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
