Use-cases for version ranges?

[Brian Pontarelli]

On Nov 18, 2011, at 9:51 AM, Dalibor Topic wrote:

> On 11/18/11 12:52 AM, cowwoc wrote:
>> I question whether such a mechanism is better or worse
>> than depending on individual versions which may be overridden at a later
>> time (a la Maven). On the one hand, you don't need to release a new version
>> of the application each time a dependency is updated. On the other hand, no
>> one is actually running tests to ensure that the versions are really
>> compatible.
> 
> I think that it's better. Consider a directed dependency graph with N nodes. One 
> of the nodes has a security issue, which gets fixed in a new release with a new 
> version, so it needs to be updated to some later version. Typically, the ABI 
> doesn't change in a security fix.
> 
> If you depend on the individual version, you in addition need to update all nodes 
> with an edge going to the updated node, potentially recursively (since you may need 
> to update the metadata to point to the updated metadata, at least). In other words,
> you have a domino effect. Consider a large N, where security updates for various third 
> party components don't happen on a synchronized schedule, and you potentially have 
> multiple domino effects happily cascading with each other ...
> https://www.youtube.com/watch?v=qybUFnY7Y8w .

If  modules define their version compatibility, you don't have these issues. Someone can pull in new versions of a module or tell a module to use a different version of a dependency and as long as it doesn't break the version compatibility.

This is how Savant works and it was built for Orbitz, which had an extremely large dependency graph. I used to have good wiki page on version compatibility, but I can't find it anymore.

The way it works is that the module developer defines how they want to maintain runtime compatibility across versions. In most cases, things are compatible across minor or patch versions. "Minor" compatibility means 1.1 and 1.2 are are compatible but not 2.0. "Patch" compatibility means 1.1.1 and 1.1.2 are compatible but not 1.2.

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.

-bp