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
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
