« Return to Thread: VOTE: Approach for sharing code
Re: VOTE: Approach for sharing code
by David Van Couvering
::
Rate this Message:
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.
>
>
>
>
[david.vancouvering.vcf]
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:david.vancouvering@...
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
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.
>
>
>
>
[david.vancouvering.vcf]
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:david.vancouvering@...
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
« Return to Thread: VOTE: Approach for sharing code
| Free embeddable forum powered by Nabble | Forum Help |
