Use-cases for version ranges?

[cowwoc]

Hi Lukas,


Lukas Krecan wrote:
> 
> 1. Author of B can not guarantee that B 1.3 is compatible with 1.2. 
> Well, he can, but he can not be trusted. Some changes can cause problems 
> that can not be envisaged  by their author. The compatibility can be 
> tested only by the users of the library!
> 

I disagree with this point. I posted a more detailed explanation of my
proposal here:
http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tt5002801.html#a5008437

I agree with you that users should be able to override the author
recommendations at runtime. However, I still believe each module's author is
best suited to declare version compatibility for his/her own module.


Lukas Krecan wrote:
> 
> 2. Author of A can not garantee that A will work with future versions of 
> B. She can only test it with existing versions of B. She can say that A 
> 3.0 is compatible with B [1.0,1.9].
> 

I think you're right that neither the author of A or B can declare with
absolute confidence about version compatibility. Ideally the system should
use the specific version of A that B depends on. I don't think anyone is
debating that. I think version substitution comes into play when an
application depends on B and C, each of which depend on different versions
of A. In such a case, the system should provide users with reasonable
defaults (recommendations) which end-users should be able to accept or
override.


Lukas Krecan wrote:
> 
> 3. Application 0 depends on A 3.0 and B 2.0 has been released. I want to 
> use it, but new version of A has not been released yet. I need to 
> override the A-> B dependency.
> 4. All programmers have left the project 0 and few months later, B  2.1 
> has been released. It contains a critical security bug fix. System 
> administrator needs to specify this dependency without having to 
> recompile the application 0. He just needs to specify the new dependency.
> 
> You see, the dependency resolution can not be fully automated. At the 
> end, some dependencies have to be specified manually regardless the 
> versioning mechanism. The cause is simple. All the components have 
> different lifecycle and only the end-user (application 0) has all the 
> data. Only him can test that the combination works as expected.
> 

As stated above, I agree that ultimately end-users should be able to
override any defaults/recommendations. I think end-users would benefit from
getting recommendations from the authors of modules they depend upon which
is why those developers should be able to specify version compatibility for
their own versions (again, this is a recommendation not a hard limit).

Gili

--
View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5008449.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.