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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
