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.
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 - even if we go this way - it's still in people's hands, i.e.
depends on a particular person to set it right or wrong. Better but
slower approach might be via declaring the API explicitly , like in OSGi
one "exports" packages and those become "official" API of a bundle. Then
we can check binary compatibility. But this also requires artificial
restrictions and different kind of developer discipline :(, may not be
applicable to general case.
So this is no different from using the same principles in versioning
your binaries - it's yet another (I agree - convenient) string.
*nixes have quite a share of problems with those "manual" declarations
as well: I saw some cases where you cannot upgrade because somebody
forgot to change the declaration, and vice versa ...
Oleg
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
