I was assuming that there was one version for all common code. I am
hesitant to version separately each common component. It seems like
that's a lot of overhead for component users -- they would have to track
version compatibility for each component independently.
It seems to me that since the common classes are deployed as a unit,
what you really want to know is if the network client or engine can work
with the common components/classes as a whole. It's not very useful if
say the 10.2 network client can work with the 10.1 i18n code but not the
10.1 DRDA encoding. It's kind of all-or-nothing.
Thanks,
David
Daniel John Debrunner wrote:
David W. Van Couvering wrote:
I added a comment to DERBY-289
(http://issues.apache.org/jira/browse/DERBY-289) that is my official
proposal for an approach to sharing code.
I am including it in this email as well for easy reference.
Please vote and/or comment on this proposal.
I'm a little confused on the versioning. Is the version number for a
common component in-line with the Derby version or independent? I was
assuming independent, but it seems from your examples that the versions
are in-line with the Derby version.
As an example, I imagine code for localization would be fairly static,
and the initial version may well remain unchanged until several Derby
releases from now (if ever). Thus I wouldn't expect the version number
of such common code to change on every Derby release.
Are you saying that all common code is at a single version, rather than
versions within the common code. Eg. I was imagining a version for
i18n/l10n code, another for say drda encoding, etc.
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
