David W. Van Couvering wrote:
I can add this, but to answer real quickly, at this point there are no
restrictions and no visible user impact.
Then you should probably add a "no" between the words "be" and "visible"
in the following sentence in the "User Visible Impact and Restrictions"
section:
"With these guidelines in place, there should in general be visible
impact or restrictions for Derby users."
;)
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
--
John
