maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCallum <gho...@apache.org>
Subject Re: Mercury Version Ranges
Date Wed, 13 Aug 2008 05:21:06 GMT
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...

-- 
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org

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


Mime
View raw message