db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: VOTE: Approach for sharing code
Date Thu, 08 Sep 2005 15:43:52 GMT
David W. Van Couvering wrote:

> 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.

Most likely a single version is fine when there are only two users of
common code (client & engine). If/once there are more users (e.g. tools)
it may get interesting. E.g. the client is coded against version 4, but
new shared code added for tools/engine bumps the version up to 9. As
long as the client continues to work with 9 (as none of the code it is
using has changed) and there are no rules like version+N is only
supported if N <=2, it should be ok.

I think what will typically happen is that sets of shared code will be
added, but their api ("version") is unlikely to change. The code may get
bug fixes, but its offered api remains the same. Thus the version
bumping (with a single version) will most likely be due to added code.

Dan.




Mime
View raw message