I can add this, but to answer real quickly, at this point there are no
restrictions and no visible user impact. If at some point we make a
change that is not forward-compatible (which by the proposed guidelines
would only be allowed across major versions like from 10 to 11), then
the user should place the jar files from the latest revisions first in
the classpath.
Your question has also reminded me to put in a note about testing
impact: we will want to add compatibility tests to ensure that
incompatible changes have not been added between releases. Note that
these tests do not need to exist until the first release *after* 10.2
(assuming the first release with common code is in 10.2).
I'll add both of these items to the policy.
David
Kathey Marsden wrote:
David W. Van Couvering wrote:
Hi, all. I'd like to have a formal vote on the shared components
guidelines as published at
http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines
A while back we talked about adding a section that would describe the
user impact and any restrictions on mixing derbyclient.jar, derby.jar
and derbytools.jar from the perspective of the user. But I don't see
that yet. What restrictions on jar mixing will exist and need to be
documented in the user documentation with this proprosal?
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
