Use-cases for version ranges?

[cowwoc]

Brian Pontarelli wrote:
> 
> I think the two fundamental issues I have with ranges are:
> 
> 1. At any given time I can only be certain my code will work with one
> version of a dependency. That is the version I compile and test against.
> Therefore, as a developer, I should only define that version in my
> dependencies meta-data. 
> 
> 2. There should not be any magic upgrading of my dependencies at run or
> build time. Someone should be forced to specifically upgrade one of my
> dependencies and only for a really good reason. They should also be forced
> to test that upgrade to ensure it will work.
> 
> Without module isolation, this problem was much more difficult because
> there could only be one version of a JAR on the classpath and therefore
> build tools needed to understand how to safely upgrade JARs. Some build
> tools did this better than others.
> 
> With true isolation, this is less of an issue, making single versions even
> easier to use. 
> 
> Issues come back into play when modules export modules or with circular
> dependencies. These mimic the classpath behavior, which in my opinion is
> best solved via compatibility rather than ranges.
> 

I can't speak for module isolation (care to explain what you mean?) but I
agree wholeheartedly with your two points. Whether we support version ranges
or end-user overrides, can we all agree that developers can only be expected
to certify that their code works with a single version of a dependency?

If so, the question becomes: what mechanism is best suited for allowing
someone other than the original developer to change the dependency
version... One approach is version ranges. Another approach is end-user
overrides. I don't understand what module isolation refers to but I suspect
that's a third option.

Gili

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