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