Use-cases for version ranges?

[Lukas Krecan]

Hi,
   it's obvious that the only one who has all the information is the 
person DEPLOYING the application (in Java EE it's Application Assembler 
role). In the enterprise word the application is maintained long after 
the implementation is finished. Imagine that there was a security 
problem in a library and a new version has been released. As a person 
taking care of the application I want just change this dependency 
without having to recompile the application.

So having an automatic resolution of dependency versions is a nice 
feature, but we will always need a way how to specify the dependencies 
at the runtime.

To reiterate, let's reuse the previous example, where 0 depends on A 
which in turn depends on B.

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!
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].
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.

    Regards
         Lukas


On 11/20/2011 04:09 AM, cowwoc wrote:
>
>     I'd like to propose another possibility: the author of the 
> dependency should tell *us* about version compatibility, not the other 
> way around. For example:
>
> 1. The author of module A declares a dependency on module B version 
> 1.2 (specific version).
> 2. The author of module B publishes version 1.3. He declares that 
> version 1.3 is compatible with 1.2 (meaning, the runtime system is 
> allows to substitute version 1.3 for 1.2).
>
>     The upside of this approach is that the author of B is in a better 
> position to declare compatibility than the author of A. The author of 
> A still only needs to test a single version. What do you think?
>
> Gili
>
> On 19/11/2011 1:59 AM, Neil Bartlett wrote:
>> Gili,
>>
>> I didn't say anything about guarantees, and in this industry I have
>> never heard of anybody providing a guarantees about the performance of
>> their software, especially in the presence of external dependencies.
>>
>> Version ranges are a means of communicating expectations, and we
>> provide both a lower and an upper bound because this is useful
>> information. I expect my module will work with 1.2.14, and I expect it
>> will not work with 2.0. If I were a provider of the API rather than a
>> consumer then I would have a much narrower expectation,  e.g.
>> [1.2,1.3), and this would also be useful information to convey.
>>
>> Regards
>> Neil
>>
>> On Sat, Nov 19, 2011 at 4:27 AM, cowwoc<cowwoc at bbs.darktech.org>  wrote:
>>> Neil,
>>>
>>>     I guess I don't understand why Jigsaw should work differently 
>>> from Maven
>>> on this point. I am expecting developers to specify specific 
>>> versions that
>>> they tested (point versions, not ranges) and end-users may override 
>>> these
>>> "recommendations" as they see fit.
>>>
>>>     Where you see version range [1.2.14, 2.0) as a way of 
>>> communicating "the
>>> developer guarantees 1.2.14 but you may use newer versions up to 2.0 
>>> at your
>>> own risk" I'd expect the developer to simply specify 1.2.14 and 
>>> there should
>>> be no limit on what version end-users may use if they so wish.
>>>
>>> Gili
>>>
>>> On 18/11/2011 2:23 AM, Neil Bartlett wrote:
>>>> I noticed that I failed to address your point about Maven using point
>>>> versions.
>>>>
>>>> Maven is a build tool. At build time we need to compile against a
>>>> single specific version so that we have repeatable builds. In general
>>>> we should build each module against the lowest version of the library
>>>> that it can possibly use, and there are no major negative consequences
>>>> of having several versions of a library at build time (except that
>>>> Maven has to download a lot!). At runtime however we need to have the
>>>> flexibility to substitute a single compatible version.
>>>>
>>>> Neil
>>>>
>>>> On Fri, Nov 18, 2011 at 7:10 AM, Neil Bartlett<njbartlett at gmail.com>
>>>>   wrote:
>>>>> Suppose as the developer of module A, I declare a dependency on 
>>>>> log4j,
>>>>> exactly version 1.0.0 because I have not tested against log4j 1.0.1,
>>>>> 1.0.2, 1.3, 999.999 etc. I effectively prevent my module *ever* being
>>>>> used with log4j version 1.0.1 even if this combinations is later
>>>>> tested and proven to work by somebody else. In other words, 
>>>>> testing is
>>>>> important but it doesn't necessarily have to always be done by the
>>>>> original developer of each module.
>>>>>
>>>>> On the other hand let's say I state my dependency using the following
>>>>> range: [1.2.14, 2.0). This is OSGi syntax and I believe Jigsaw is
>>>>> following it, and it simply means I accept version 1.2.14 up to but
>>>>> not including 2.0. Anybody can see that I compiled and tested against
>>>>> 1.2.14, but has the option of using 1.2.15, 1.2.16, 1.3, 1.9 etc. It
>>>>> does not mean that I *guarantee* my module will work with log4j 1.3
>>>>> because that obviously depends on whether the log4j authors accept 
>>>>> and
>>>>> follow the common semantics of indicating backwards-incompatible
>>>>> changes with a bump to the first version segment.
>>>>>
>>>>> The consequence of trying to lock down imports to a narrow range or
>>>>> even a point version is that assembling an application becomes very
>>>>> difficult, and we are forced to deploy many versions of common
>>>>> libraries concurrently. This is non-optimal, though we can handle it
>>>>> to some degree via per-module classloaders as in OSGi.
>>>>>
>>>>> Regards,
>>>>> Neil
>>>>>
>>>>> On Thu, Nov 17, 2011 at 11:52 PM, 
>>>>> cowwoc<cowwoc at bbs.darktech.org>    wrote:
>>>>>> Can someone please explain why modules need to be able to specify
>>>>>> version
>>>>>> ranges for dependencies? I believe OSGI allows the specification of
>>>>>> version
>>>>>> ranges while Maven allows the specification of individual versions.
>>>>>>
>>>>>> The only thing that comes to mind is when module C depends on A 
>>>>>> and B, A
>>>>>> depends on log4j 1.0, and B depends on log4j 1.1. What does C do? Is
>>>>>> this
>>>>>> the main use-case for version ranges?
>>>>>>
>>>>>> By the sound of it, this is a trust model where developers are 
>>>>>> told that
>>>>>> log4j 1.x won't break compatibility so they depend on that range 
>>>>>> without
>>>>>> actually testing against each version (newer versions may be 
>>>>>> released
>>>>>> after
>>>>>> their own software). 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.
>>>>>>
>>>>>> Is there a way to get module A to see log4j 1.0 and module B to see
>>>>>> log4j
>>>>>> 1.1 (using separate ClassLoaders)?
>>>>>>
>>>>>> Thanks,
>>>>>> Gili
>>>>>>
>>>>>> -- 
>>>>>> View this message in context:
>>>>>> http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5002801.html 
>>>>>>
>>>>>> Sent from the jigsaw-dev mailing list archive at Nabble.com.
>>>>>>
>>>
>