Use-cases for version ranges?

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Use-cases for version ranges?

cowwoc
Administrator
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
Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Neil Bartlett
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 <[hidden email]> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Neil Bartlett
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 <[hidden email]> 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 <[hidden email]> 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.
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Thomas Diesler
In reply to this post by Neil Bartlett
Yes OSGi uses a version scheme with semantic meaning (see the whitepaper
on Semantic Versioning
<http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf> for
details). This works very well as long as the world conforms to the
semantic meaning of that scheme. In reality we see a wide vararity of
versioning schemes being used - not all of them make sense let alone can
be used to reason about compatibility.

At jboss we use a model whereby the identity of a module is defined by
'identifier' plus 'slot'. A slot is not necessarily a version/range but
a compatibility expression. The default slot is 'main' and would
initially contain the version of the jar that you use to begin with

org.log4j:main => log4j-1.2.14.jar

Modules that have a dependency on log4j would use 'org.log4j:main' to
express that. When there is an update to log4j, we can replace the
binary in the same slot with the newer version as long as it is
compatible (QA would check that). An incompatible version (e.g.
log4j-2.0) can be installed on a new slot (e.g. 2x) and clients can be
updated accordingly.

Unlike OSGi, the dependency may be expressed within the deployment that
has the dependency or externally as we do for all system components.

OSGi requires that the unit of deployment is the 'bundle' for which it
mandates that it uses semantic versioning mainly for its package
import/exports.

Bottom line: dependencies based on version ranges makes sense if there
is a compatibility contract associated with version strings. (i.e. you
must have some fidelity that 1.2 is backward compatible to 1.1 but 2.0
is not)

-thomas

On 11/18/2011 08:10 AM, Neil Bartlett 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<[hidden email]>  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.
>>

--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Sangjin Lee
Fixed versions become problematic if your runtime consists of modules that
were not created by you and cannot be modified to coordinate their
versions. And that is a fairly common occurrence.

For example, suppose your module A depends on a third-part module B of
version 1.2.3 (and that only). But A also depends on another (unrelated)
third-party library module C of version 1.0.0. Furthermore, suppose C also
depends on B but of version 1.1.0 (and that only).

If we do not allow version ranges, this runtime would have to bring in both
versions of B into it. Depending on how B is used, this may lead to runtime
problems such as ClassCastExceptions. And this can quickly proliferate
especially if B is a popular library.

If you can modify C's module metadata to agree to whatever a common version
of B is, that would address this issue. However, that may not be always
doable or practical.

Version ranges are useful if there is actually room for different consumers
to agree on a common version of the provider. Yes, semantic versions play a
big part here, but IMO the alternatives are not as attractive.

BTW, the current JDK behavior can be considered as having a completely open
version range (0 to infinity). Once you're on the classpath, you're willing
(and forced) to accept any version. Using a fixed version is the other
extreme.

Regards,
Sangjin

On Fri, Nov 18, 2011 at 7:26 AM, Thomas Diesler <[hidden email]>wrote:

> Yes OSGi uses a version scheme with semantic meaning (see the whitepaper
> on Semantic Versioning <http://www.osgi.org/wiki/**uploads/Links/**
> SemanticVersioning.pdf<http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf>>
> for details). This works very well as long as the world conforms to the
> semantic meaning of that scheme. In reality we see a wide vararity of
> versioning schemes being used - not all of them make sense let alone can be
> used to reason about compatibility.
>
> At jboss we use a model whereby the identity of a module is defined by
> 'identifier' plus 'slot'. A slot is not necessarily a version/range but a
> compatibility expression. The default slot is 'main' and would initially
> contain the version of the jar that you use to begin with
>
> org.log4j:main => log4j-1.2.14.jar
>
> Modules that have a dependency on log4j would use 'org.log4j:main' to
> express that. When there is an update to log4j, we can replace the binary
> in the same slot with the newer version as long as it is compatible (QA
> would check that). An incompatible version (e.g. log4j-2.0) can be
> installed on a new slot (e.g. 2x) and clients can be updated accordingly.
>
> Unlike OSGi, the dependency may be expressed within the deployment that
> has the dependency or externally as we do for all system components.
>
> OSGi requires that the unit of deployment is the 'bundle' for which it
> mandates that it uses semantic versioning mainly for its package
> import/exports.
>
> Bottom line: dependencies based on version ranges makes sense if there is
> a compatibility contract associated with version strings. (i.e. you must
> have some fidelity that 1.2 is backward compatible to 1.1 but 2.0 is not)
>
> -thomas
>
>
> On 11/18/2011 08:10 AM, Neil Bartlett 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<[hidden email]**>
>>  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<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.
>>>
>>>
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Dalibor Topic
In reply to this post by cowwoc
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 .

cheers,
dalibor topic
--
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
Reply | Threaded
Open this post in threaded view
|

Re: 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

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

cowwoc
Administrator
In reply to this post by Neil Bartlett
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<[hidden email]>  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<[hidden email]>  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.
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

cowwoc
Administrator
In reply to this post by Brian Pontarelli
Brian Pontarelli wrote
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.
I can't speak for module isolation (care to explain what you mean?) but I agree wholeheartedly with your two points. Whether we support version ranges or end-user overrides, can we all agree that developers can only be expected to certify that their code works with a single version of a dependency?

If so, the question becomes: what mechanism is best suited for allowing someone other than the original developer to change the dependency version... One approach is version ranges. Another approach is end-user overrides. I don't understand what module isolation refers to but I suspect that's a third option.

Gili
Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Neil Bartlett
In reply to this post by cowwoc
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 <[hidden email]> 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<[hidden email]>
>>  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<[hidden email]>  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.
>>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Nicolas Lalevée
In reply to this post by cowwoc

Le 19 nov. 2011 à 05:32, cowwoc a écrit :

>
> Brian Pontarelli wrote:
>>
>> 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.
>>
>
> I can't speak for module isolation (care to explain what you mean?) but I
> agree wholeheartedly with your two points. Whether we support version ranges
> or end-user overrides, can we all agree that developers can only be expected
> to certify that their code works with a single version of a dependency?
>
> If so, the question becomes: what mechanism is best suited for allowing
> someone other than the original developer to change the dependency
> version... One approach is version ranges. Another approach is end-user
> overrides. I don't understand what module isolation refers to but I suspect
> that's a third option.

I'm not sure either how module isolation would help either. But I think there's solution we don't want to see because we fear duplicates, redundancy, this is error prone: having two dependency descriptors.
But as Neil already wrote it: "At build time we need to compile against a single specific version so that we have repeatable builds. [...] At runtime however we need to have the flexibility to substitute a single compatible version." Since we want to declare two very different things, I don't think of no other way than having two kinds of declaration. And note that these two declarations will be used at very different times. The first will be used while we construct the classpath (to build or to deploy), the other by the jvm at runtime to ensure modularity.

I think I have a solution. I'm experimenting it with Ivy (which is good at building classpath) and OSGi (which is good at runtime dependencies). A project in development would have an ivy.xml in which I would declare the dependency I want to build, test, run against. It could looks like a dependency on commons-logging 1.0. I make Ivy resolves and retrieves my dependencies against an OSGi repository (I'll explain why later), so I get my jars in a lib folder.
Then I need to make my project runnable in an OSGi environment, so I need an other descriptor. I need to redeclare my dependency in a MANIFEST ? Actually no since OSGi dependency model is nicely integrated in the Java environment, no extra namespace, just java packages. So my dependencies are already declared by my java import in every of my classes. And there's nice tools (bnd, bundlor) to compute the MANIFEST automatically. So no burden. In the MANIFEST I would then have a dependency on the package org.apache.commons.logging.
Last but not least, the release of the project. Since I don't want the users of my project to be tied to the dependencies I chose in my ivy.xml, I shouldn't publish it. Instead, users should be aware of what my project is requiring, which API must be fullfield: the information is in the MANIFEST. The end users should fulfill the requirement on the package org.apache.commons.logging by either the implementation bundle commons-logging or the bundle jcl-over-slf4j. So I'll publish only the OSGi metadata, hence my project should be publish to an OSGi repository.
And the development cycle is closed.

There's one thing to note about the Ivy resolve against an OSGi repository. As the OSGi Bundle Repository spec draft nicely state: "SHALL NOT be required to produce identical sets of resolved resources throughout every phase of the development process." Since the inherent  "flexibility" nature of the dependency declaration of an OSGi bundle, two resolves at different times may result in two different classpath. Hence the Ivy resolve would be done only one to build a classpath. And only do it again on dependency change. In Eclipse world, this is what is called an target platform.

This is the best dependency management I have found so far. I have to admit it is theoretical, Ivy's model is not yet ready to understand OSGi dependency model.

A last note on the solution on overriding dependencies. This really looks like a hack to me. The developer of a module A declare a dependency on module B and we say, no, it's actually module C. For me it it like changing the visibility of a method from private to public via introspection.

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

cowwoc
Administrator
On 19/11/2011 5:51 AM, Nicolas Lalevée [via jigsaw-dev] wrote:
> A last note on the solution on overriding dependencies. This really
> looks like a hack to me. The developer of a module A declare a
> dependency on module B and we say, no, it's actually module C. For me
> it it like changing the visibility of a method from private to public
> via introspection.

     We aren't substituting module B for module C. We are substituting
module B version 1.0 with module B version 1.1. So long as we substitute
for a version which is compatible wiht version 1.0 why should the author
care?

Gili
Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

cowwoc
Administrator
In reply to this post by Neil Bartlett

     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<[hidden email]>  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<[hidden email]>
>>>   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<[hidden email]>    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.
>>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Stephen McConnell

I could say that the question is academic - but here is the thing - its not
even academic.

We talk about versions and yet the platform has no computational mechanisms
to flag version violation. At least an academic discussion would bring in
grounded metrics.  In reality - the discussion here about V1 versus V2 and
that warm fuzzy feeling when your are just a n.m from an n+1 and it's a
waste of breath (and that comment goes to all sides of the debate).

Give me an endorsed tool that shows me that module [name]-[build] is
computationally backward compatible to a different [name]-[build] and then,
only them will this discussion have reasonable grounds to assert any
authority on the subject of version compatibility (past or future). Without
that tool - versioning is a unqualified statement of trust. And the evidence
suggests that the threshold of trust delivery on actual computational
compliance is really really thin.

Cheers, Steve.


-----Original Message-----
From: cowwoc
Sent: Sunday, November 20, 2011 1:39 PM
To: [hidden email]
Subject: Re: Use-cases for version ranges?


     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<[hidden email]>  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<[hidden email]>
>>>   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<[hidden email]>
>>>> 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.
>>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Nicolas Lalevée
In reply to this post by cowwoc

Le 20 nov. 2011 à 03:55, cowwoc a écrit :

> On 19/11/2011 5:51 AM, Nicolas Lalevée [via jigsaw-dev] wrote:
>> A last note on the solution on overriding dependencies. This really
>> looks like a hack to me. The developer of a module A declare a
>> dependency on module B and we say, no, it's actually module C. For me
>> it it like changing the visibility of a method from private to public
>> via introspection.
>
>     We aren't substituting module B for module C. We are substituting
> module B version 1.0 with module B version 1.1. So long as we substitute
> for a version which is compatible wiht version 1.0 why should the author
> care?


The author probably not, but what about the module system in the jvm ? The dependency declarations are for the module system so it can correctly ensure modularity.

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Nicolas Lalevée
In reply to this post by Stephen McConnell

Le 20 nov. 2011 à 13:25, Stephen McConnell a écrit :

>
> I could say that the question is academic - but here is the thing - its not even academic.
>
> We talk about versions and yet the platform has no computational mechanisms to flag version violation. At least an academic discussion would bring in grounded metrics.  In reality - the discussion here about V1 versus V2 and that warm fuzzy feeling when your are just a n.m from an n+1 and it's a waste of breath (and that comment goes to all sides of the debate).
>
> Give me an endorsed tool that shows me that module [name]-[build] is computationally backward compatible to a different [name]-[build] and then, only them will this discussion have reasonable grounds to assert any authority on the subject of version compatibility (past or future). Without that tool - versioning is a unqualified statement of trust. And the evidence suggests that the threshold of trust delivery on actual computational compliance is really really thin.

I haven't use it myself here is a tool which is about backward compatibility check automation:
http://www.eclipse.org/pde/pde-api-tools/

Nicolas

>
> Cheers, Steve.
>
>
> -----Original Message----- From: cowwoc
> Sent: Sunday, November 20, 2011 1:39 PM
> To: [hidden email]
> Subject: Re: Use-cases for version ranges?
>
>
>    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<[hidden email]>  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<[hidden email]>
>>>>  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<[hidden email]> 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.
>>>>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Neil Bartlett
In reply to this post by Stephen McConnell
Stephen,

You again seem to be talking about dependencies on implementation
packages. If we depend on APIs consisting primarily of interfaces,
then versions and version ranges are reliable and can be completely
automated.

Regards,
Neil


On Sun, Nov 20, 2011 at 12:25 PM, Stephen McConnell <[hidden email]> wrote:

>
> I could say that the question is academic - but here is the thing - its not
> even academic.
>
> We talk about versions and yet the platform has no computational mechanisms
> to flag version violation. At least an academic discussion would bring in
> grounded metrics.  In reality - the discussion here about V1 versus V2 and
> that warm fuzzy feeling when your are just a n.m from an n+1 and it's a
> waste of breath (and that comment goes to all sides of the debate).
>
> Give me an endorsed tool that shows me that module [name]-[build] is
> computationally backward compatible to a different [name]-[build] and then,
> only them will this discussion have reasonable grounds to assert any
> authority on the subject of version compatibility (past or future). Without
> that tool - versioning is a unqualified statement of trust. And the evidence
> suggests that the threshold of trust delivery on actual computational
> compliance is really really thin.
>
> Cheers, Steve.
>
>
> -----Original Message----- From: cowwoc
> Sent: Sunday, November 20, 2011 1:39 PM
> To: [hidden email]
> Subject: Re: Use-cases for version ranges?
>
>
>    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<[hidden email]>  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<[hidden email]>
>>>>  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<[hidden email]>
>>>>> 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.
>>>>>>
>>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Lukas Krecan
In reply to this post by cowwoc
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<[hidden email]>  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<[hidden email]>
>>>>   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<[hidden email]>    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.
>>>>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Stuart McCulloch
In reply to this post by cowwoc
On 20 Nov 2011, at 03:09, 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).

Note that the author of module B could also do this by following a semantic versioning scheme [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?

You might want to read the Multiple Versions section from this entry on Peter's blog [3] where he raises the question of whether the importer or exporter is best placed to express compatibility.  This later blog entry [4] about versioning is also worthwhile reading.

PS. while most people use a single version for Maven dependencies, you can in fact use version ranges to restrict the resolution process [5]. Microsoft also decided to use ranges in their NuGet package system [6].

[1] http://semver.org/
[2] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
[3] http://www.osgi.org/blog/2008/02/research-challenges-for-osgi.html
[4] http://www.osgi.org/blog/2009/12/versions.html
[5] http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges
[6] http://docs.nuget.org/docs/reference/version-range-specification

> 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<[hidden email]>  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<[hidden email]>
>>>>  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<[hidden email]>    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.
>>>>>>
>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Use-cases for version ranges?

Stuart McCulloch
In reply to this post by Lukas Krecan
On 20 Nov 2011, at 15:51, Lukas Krecan wrote:

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

Would you agree that the deployer's life can be made easier if people try to follow the same semantic versioning scheme? That at least gives the deployer some idea of the intent of the developer, which they can confirm by testing. It also means that they are less likely to be surprised by unexpected incompatibilities (I'm not saying this would never occur, just that it should be less likely).

--
Cheers, Stuart

>   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<[hidden email]>  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<[hidden email]>
>>>>>  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<[hidden email]>    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.
>>>>>>>
>>>>
>>
>

123