Use-cases for version ranges?

[Brian Pontarelli]

One other way I look at version ranges is that it is like guessing the future. If I publish something that contains a version range with versions that haven't been released yet, I'm essentially guessing that another developer will maintain compatibility according to my version range.

For example, if I specify this:

log4j (1.0, 2.0]

I'm essentially just guessing that the Log4j team will be cool and maintain compatibility from the current version of 1.2.16 all the way through 2.0. This really isn't my job or a good idea in my opinion.

-bp

On Nov 18, 2011, at 11:59 PM, 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.
>>>>> 
>> 
>>