maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Mercury Version Ranges
Date Wed, 13 Aug 2008 05:42:17 GMT


Michael McCallum wrote:
> On Wed, 13 Aug 2008 16:35:38 Ralph Goers wrote:
>   
>> Michael McCallum wrote:
>>     
>>> To be well rounded we should consider other approaches to dependencies
>>>
>>> its worth having a look at how gentoo does versioning with ranges and
>>> slots... http://www.gentoo.org/
>>> http://devmanual.gentoo.org/general-concepts/dependencies/index.html
>>> http://devmanual.gentoo.org/general-concepts/slotting/index.html
>>>       
>> Yes, but... What has really made Linux package management work is more
>> than just versioning.
>>     
> not sure why you said but... i agree with everything you are saying...
>
>   
>> In your previous email you wrote -
>>
>> module Z released as 2.X
>> a dependent module Y specifies X [2,3)
>> you now make a breaking change and release the alpha version of Z
>> 3.0-alpha-1 and BAM module Y is using it when it explicitly said I only
>> want major version 2
>>
>>
>> This is exactly where I have a problem with the whole thing. You
>> probably specified [2,3] under the assumption that all version 2
>> releases would be compatible. You probably also are assuming the version
>> 3 isn't compatible with version 2. Either or both of these assumptions
>> could be invalid.
>>     
> agreed, i have cooked my own slotting/provides by introducing my own packages 
> that i depend upon which then transition to builds that are known to be 
> compatible...
>
> you don't HAVE to have slots or requires/provides
>
> so i define but it could just as easily be the package maintainer that does an 
> composite artifact... lets take spring as an example
>
> i know that there are three groups of compatible springs 1.2.X, [2.0, 2.5) and 
> [2.5, 2.6)
>
> so i have three spring artifacts my.artifact.composite.spring-1.2.Y, 
> my.artifact.composite.spring-2.0.Y and my.artifact.composite.spring-2.5.Y 
> where Y is an incrementing revision number not related upstream
> each of these defines a specific range e.g. spring-core-[2.5,2.5.1] that 
> fullfil the contract
>
> where i have projects that use the spring 2.5 compatible code they  depend 
> upon my.artifact.composite.spring-[2.5,2.6-!)... i can upgrade that composite 
> to include a new spring release if I think its compatible... if spring were 
> to release a 2.6 and i found it not compatible i would make a new 
> composite.... 
>
> now obviously there is overhead to this... and each company would need to make 
> its own call...but i've found the overhead of extra artifacts with just dep 
> lists very low... it can even include units tests with assumptions about the 
> composed libraries to help with validating compatibility...
>
> hope that all makes sense.... i'm doing a presentation at a JUG in a few weeks 
> so should have some pretty slides and examples of this soon...
>   
Yes, this works in a fashion. But the problem is pretty much taken right 
out of what you've stated. You know there are 3 groups of compatible 
Springs, presumably because you investigated. What about Xerces, Xalan, 
httpclient, commons-lang and on and on. This has to be repeated in every 
company. The silly part is that every one of these projects will know 
which versions are incompatible and could make everyone's life easier by 
just declaring it.  Yes, people will still make mistakes. But people 
tend to fix them when enough people complain.

To be honest, even with this I'd still probably not use version ranges. 
But I sure would like for Maven to be able to fail the build because two 
artifacts need incompatible versions of the same thing.

Ralph

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


Mime
View raw message