Daniel John Debrunner wrote:
David W. Van Couvering wrote:
As suggested by many of you, here is a call vote on the overall
intention for how we want to share code, without bogging down in the
details. Thanks to Kathey for a very helpful suggested wording.
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 will
need to separate the two versions by using separate classloaders.
Is this a requirement, 'will need', since the wiki page says "We should
strive for forward compatibility between major releases, ..." and
elsewhere in referring to incompatibility between major releases it says
"(and this is to be avoided)"?
Perhaps I misunderstood, but I thought Kathey felt that if we did not
*guarantee* compatibility then it would be simpler and more correct to
say that a user should expect and plan for incompatibility between major
releases, rather than hope and pray for compatibility.
I would prefer to word it something like "may need" instead of "will
need" but I was concerned about pushback from Kathey :)
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.
I'm a little nervous of the use of and reliance on "major version",
since we don't have any guidelines as to when we would change major
version number. One could read this vote as saying I can break the
compatibility at any time by just bumping the major version. Is shared
code really the driver for major version changes?
Does specifying major version add any value to your proposal? Maybe you
could take the approach that at all times we strive for compatibility.
If someone in the future wants a change that would cause some
compatibility issues, they could raise it then with a vote.
Hm. I do know that it's standard practice to say that incompatibilities
of any sort of interface be cause for a bump in major version.
I personally would have interpreted this as saying that if someone
attempts to introduce an incompatibility they will have to wait until
the next major release, just as if someone were to propose changing the
database file format in an incompatible way or modifying the 'ij'
interface in some incompatible way.
In other words, the intent was to provide pushback for incompatible
changes, not motivation for more frequent major releases.
What I could say is something like "at all time we strive for
compatibility. If someone in the future wants a change that would cause
some compatibility issues, they could raise it with a vote. Such a
change would require a bump in the major release."
The last sentence is consistent with the the Jakarta Commons versioning
guidelines at http://jakarta.apache.org/commons/releases/versioning.html
-- "Major releases signify significant changes to a component.
Developers *may* perform a major release if there have been substantial
improvements to the component. Developers *must* perform a major release
whenever the new release is not at least interface-compatible the
previous release."
My point being that our guidelines need to allow customers to be assured
that that they will *never* see interface incompatibilities between
minor releases, whereas there is a *possibility* that there is an
incompatibility between major releases.
Dan.
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
