db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: VOTE: Approach for sharing code
Date Thu, 08 Sep 2005 13:16:45 GMT
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.
>
>
>  
>

Mime
View raw message