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 04:35:38 GMT


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.

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.

The real problem here, at least as I see it, is that Y incorporated Z at 
some release of 2.x.  In reality it really shouldn't care if it is using 
version 2.x, 3.x, 4.x, etc. as long as the behavior of what it is using 
is still the same.  The various flavors of Unix have been successfully 
dealing with this for years. If you look at an RPM you will see that it 
not only has a "requires" element, which is equivalent to Maven's 
depdencies, but it also has a "provides" element, which Maven has no 
equivalent of. Without that you can have all the fancy version schemes 
you want but they will never be reliable. Interestingly, whatever is 
provided is not allowed to have a version associated with it - but if 
you look at how it is typically used it will be something like libc.so.1 
or libx.so.3 - which, of course, has a version in its name.

So what I would really prefer is the ability to do

<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-lang</artifactId>
  <requires>commons-lang-api-2</requires>
</dependency>

Then commons-lang would be declared as

  <groupId>commons-lang</groupId>
  <artifactId>commons-lang</artifactId>
  <version>3.0</version>
  <provides>commons-lang-api-2,commons-lang-api-3</provides>

This would then declare that version 3.0 is indeed compatible at the api level with version
2.

Ralph



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


Mime
View raw message