db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Mon, 03 Oct 2005 19:03:25 GMT
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.



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

View raw message