You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David W. Van Couvering" <Da...@Sun.COM> on 2005/10/03 21:03:25 UTC
Re: Modular build, was: VOTE: Approach for sharing code
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
Re: Modular build, was: VOTE: Approach for sharing code
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks, Kathey, I missed that, I'll add that to this page.
David
Kathey Marsden wrote:
> David W. Van Couvering wrote:
>
>
>>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 will there be another document that describes the packaging and
> any external impact of this change or will it be included in this one?
>
> Thanks
>
> Kathey
>
>
Re: Modular build, was: VOTE: Approach for sharing code
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> 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 will there be another document that describes the packaging and
any external impact of this change or will it be included in this one?
Thanks
Kathey
Re: Modular build, was: VOTE: Approach for sharing code
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Sorry, pilot error, I needed to log in.
David W. Van Couvering wrote:
> Hm, the front page appears to be an "Immutable Page." Is this perhaps
> because someone started editing it and didn't commit/back out their
> changes?
>
> David
>
> Daniel John Debrunner wrote:
>
>> David W. Van Couvering wrote:
>>
>>
>>> 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.
>>
>>
>>
>> Is there any reason this (and other wiki pages added by folks) are not
>> linked into the front page of the wiki? Is this just standard wiki
>> practice or are we just missing making the pages more visible?
>>
>> It seems like unless you know of the page then it's hard to join in any
>> discussion about it, the automated wiki diffs sent to the committer list
>> are basically unreadable.
>>
>>
>>
>> Dan.
>>
Re: Modular build, was: VOTE: Approach for sharing code
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Hm, the front page appears to be an "Immutable Page." Is this perhaps
because someone started editing it and didn't commit/back out their changes?
David
Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>
>
>>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.
>
>
> Is there any reason this (and other wiki pages added by folks) are not
> linked into the front page of the wiki? Is this just standard wiki
> practice or are we just missing making the pages more visible?
>
> It seems like unless you know of the page then it's hard to join in any
> discussion about it, the automated wiki diffs sent to the committer list
> are basically unreadable.
>
>
>
> Dan.
>
Re: Modular build, was: VOTE: Approach for sharing code
Posted by Kathey Marsden <km...@sbcglobal.net>.
David W. Van Couvering wrote:
> I can gladly add this to the front page, and perhaps we can make this
> a general policy. I would like to suggest that we have a sub-page off
> the front page for proposals that are being discussed/reviewed on the
> Wiki site.
>
That sounds like a good idea.
Re: Modular build, was: VOTE: Approach for sharing code
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I can gladly add this to the front page, and perhaps we can make this a
general policy. I would like to suggest that we have a sub-page off the
front page for proposals that are being discussed/reviewed on the Wiki site.
David
Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>
>
>>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.
>
>
> Is there any reason this (and other wiki pages added by folks) are not
> linked into the front page of the wiki? Is this just standard wiki
> practice or are we just missing making the pages more visible?
>
> It seems like unless you know of the page then it's hard to join in any
> discussion about it, the automated wiki diffs sent to the committer list
> are basically unreadable.
>
>
>
> Dan.
>
Re: Modular build, was: VOTE: Approach for sharing code
Posted by Daniel John Debrunner <dj...@debrunners.com>.
David W. Van Couvering wrote:
> 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.
Is there any reason this (and other wiki pages added by folks) are not
linked into the front page of the wiki? Is this just standard wiki
practice or are we just missing making the pages more visible?
It seems like unless you know of the page then it's hard to join in any
discussion about it, the automated wiki diffs sent to the committer list
are basically unreadable.
Dan.