commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [all] how to deal with dependency versions
Date Thu, 09 Jun 2005 21:03:14 GMT
On Wed, 2005-06-08 at 08:19 +0200, Mario Ivankovits wrote:
> Hi!
> 
> I would like to know how to deal with versions of dependend libraries.
> 
> Naturally VFS do have a bunch of dependencies, some of them are actively 
> developed.
> 
> As far as I know a non-backward compatible change in the public api 
> requires a n.0 release where
> 
> x.0 = current release
> x+1.0 = deprecated methods
> n.0 = deprecated methods removed
> 
> That way one might have enough time to prepare for the change.
> 
> 
> Now a concrete exmple for dependency versions:
> Ant 1.5 is a dependency for VFS if one would like to use its ant tasks.
> Now there is a problem with Ant 1.6 when using sub-tasks. (BTW: I found 
> a solution which still requires only 1.5, but its a little bit hacky)
> 
> Now how could the upgrade look like?
> Release VFS 1.0 with the current set of versions and upgrade to Ant 1.6 
> for VFS 1.1?
> But then VFS uses a new ant Interface introduced in Ant 1.6.(2?) and 
> fails if the user do not upgrade ant too.
> So even the public VFS api didnt change VFS 1.1 is not compatible to VFS 
> 1.0 due to the depency upgrade.

this sounds like a very tricky problem. 

i don't have any solutions but one possible approach would be to factor
so the dependencies were separated from the core. this would allow ant
1.6 support to be added alongside ant 1.5 support for the next release.
jelly takes this approach.

- robert


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message