Use-cases for version ranges?

[Neil Bartlett]

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