Use-cases for version ranges?

[Brian Pontarelli]

That's what I was referring to when I brought up "version compatibility" and it is way that Savant handles this. Only the author should be responsible for knowing how their code is compatible.

-bp



On Nov 19, 2011, at 8:09 PM, 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.
>>>>>> 
>>> 
>