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: VOTE: Principles of sharing code
Date Wed, 26 Oct 2005 16:26:15 GMT
Well, I am very confused, I could have sworn you had suggested this very 
approach of getting a vote on the principles of the thing, and then as a 
second phase submitting code that demonstrates an initial implementation.

In terms of getting the wording right, I can see your point, but to be 
honest I thought I *had* the wording right. I'm not sure how I can know 
absolutely positively that I have everyone's buyin before submitting for 
a vote without actually having a vote.

If you all would rather see code, fine, but as I understood it the 
suggestion I got from Dan (with a +1 from Andrew) was to do things 
incrementally, by voting on the overall principles first and then 
submitting a patch that can be reviewed/approved using the standard 
mechanisms.

---

It seems to me we are very very close to having something people are 
happy with.  If I were to change the wording

FROM

"If the major version of the jars loaded in a JVM differ, the user will 
need to separate the two versions by using separate classloaders. "

TO

"If the major version of the jars loaded in a JVM differ, the user may 
need to separate the two versions by using separate classloaders.  If an 
incompatibility exists, it will be clearly documented.  Any undocumented 
incompatibilities will be treated as a bug."

would anyone be unhappy with this?  PLEASE let me know by Friday.  If I 
don't hear any objections I will put it up for (sigh) another vote.

To answer your question about deprecation, yes, mixed jars between major 
versions may not work together at some point.  But just because say jar 
files between 10.0 and 12.0 do not work together does not mean that jar 
files between 11.0 and 12.0 or between 11.0 and 13.0 will not work 
together.  It does mean that jar files between 13.0 and 10.0 will not 
work together.

David

For your reference, here is the complete amended text below.

==

This vote is to support the overall intention to implement a framework 
to allow code sharing across the Derby product jars that will allow 
Derby jars of the same major version to be loaded in a Java VM without 
having to use specialized classloaders.  Forward and backward 
compatibility between jar files within the same major version will be 
implemented using versioning, compatibility tests, and an explicit 
procedure for deprecating internal APIs.

If the major version of the jars loaded in a JVM differ, the user may 
need to separate the two versions by using separate classloaders.  If an 
incompatibility exists, it will be clearly documented.  Any undocumented 
incompatibilities will be treated as a bug.

This implementation will not have any significant impact on jar file 
size or otherwise affect product distribution or usage.

The detailed guidelines are being documented and refined on the Derby 
Wiki site at 
http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines.


Kathey Marsden wrote:
> Daniel John Debrunner wrote:
> 
> 
>>I much prefer the approach in the wiki page, strive for compatibility.
>>If such a requirement comes up for a specific release, then we can
>>document that sharing jars between 12.x and 13.x is not supported.
>>
>> 
>>
> 
> Sounds ok to  me as long as such an incompatibility is documented and in
> the absence of such documentation  is treated as a bug.    I'd just like
> the user impact to be clear in the documentation and not have a
> situation where mixing jars breaks and we say "Hey  we really do strive
> for compatibility as much as possible, but we never guaranteed it would
> work."
> 
> Don't the internal interface deprecation guidelines mean that mixed jars
> will stop working together at some point?
> 
> BTW, if this thing gets submitted to vote again.  I'd like to suggest we
> get  consensus on the wording before it does.
> I'd much prefer David just submit the code to share messages with some
> really clear  way to version the messages into the future that doesn't
> break anything and then you'd get no trouble from me.
> 
> Kathey
> 
> 

Mime
View raw message