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