maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Gusakov <oleg.subscripti...@gmail.com>
Subject Re: Mercury Version Ranges
Date Wed, 13 Aug 2008 05:12:54 GMT


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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

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


Mime
View raw message