Specifying dependencies on Module Versions

I was wondering what the format for designating module dependencies is?  I've added the ability for developers to add module dependencies to KAR files but it does not take into account any information about the version of the module.  It only works with the module name at the moment, which is equivalent to saying "All versions" of the module.

I'll paste here sections 3.2.5 and 3.2.6 of the OSGi spec release 4 version 4.2, available in full at

this is the kind of thing that I am looking for for Kepler modules.

Thanks!

Version

Version specifications are used in several places. A version token has the fol- lowing grammar:

version    ::= major( '.' minor ( '.' micro ( '.' qualifier )? )? )?

major    ::= number    // See 1.3.2 minor ::=number micro ::=number qualifier ::= ( alphanum | ’_’ | '-' )+

A version token must not contain any white space. The default value for a version is 0.0.0.

Version Ranges

A version range describes a range of versions using a mathematical interval notation. See [31] Mathematical Convention for Interval Notation.

The syntax of a version range is:

version-range ::= interval | atleast interval ::= ( '[' | '(' ) floor ',' ceiling ( ']' | ')' ) atleast ::= version floor ::= version ceiling ::= version

If a version range is specified as a single version, it must be interpreted as the range [version,∞). The default for a non-specified version range is 0, which maps to [0.0.0,∞).

Note that the use of a comma in the version range requires it to be enclosed in double quotes. For example:

Import-Package: com.acme.foo;version="[1.23, 2)", com.acme.bar;version="[4.0, 5.0)"

In the following table, for each specified range in the left-hand column, a version x is considered to be a member of the range if the predicate in the right-hand column is true.

Thanks, Aaron. This is very useful for background.  We certainly should be able to specify version and version ranges for module dependencies, and this seems like a reasonable starting point for a proposal.

Matt

Are we still using this forum?

First, I do not believe it should be the responsibility of the KAR system itself to load modules. It should be the responsibility of the Module Manager. However, I do think it would be very useful to store the version of the precise modules that were present when a workflow was developed somewhere in the KAR file. It appears that we are in the process of developing systems that are in conflict with each other. Therefore, until we resolve this via Kepler management, I request that further work on this of yours be considered a prototype and occur in a separate module outside of the kepler suite. I will do likewise.

Second, specifying entire ranges of possible dependencies might be okay, but I think we should think critically about whether we want or need this feature. What does it mean for two modules to "work" together. Does it mean that for all possible workflows, all modules within the range will give you identical results? This would imply that the only changes between the versions of modules are non-substantive bug fixes or performance improvements. That is, that the changes constitute patches, not major or minor releases. By contrast, if workflows are not guaranteed to yield identical results (as when a major or minor release is made), then I do not think it makes sense to say, for the purpose of a particular workflow, that the modules are interchangeable. In fact, I think this would be poisonous to scientific workflows, because repeatability is a very important objective.

Anyway, I am working on this very same problem in my prototype of the new module manager. And the versions I use works like this:

A published module must refer to another module either down to the exact patch level. (i.e. foo-1.1.3 depends on bar-2.1.4) or it can say that the latest patch is acceptable (i.e. foo-1.1.3 depends on bar-2.1.^). In the system I am developing, it does not make sense to say that a workflow can either use bar-2.4.6 or bar-3.0.0 interchangeably, because major and minor updates are NOT guaranteed to be semantically equivalent, as patches are supposed to be. If something is in fact semantically equivalent to bar-2.4.6, then it should be released as bar-2.4.7 or bar-2.4.X, not as bar-3.0.0 or bar-2.5.0). That is, things that are guaranteed to be semantically equivalent (they are bug fixes or performance optimizations) should be published as patches and not as major or minor releases. Things that are not bug fixes or performance improvements and are not semantically equivalent should be published as major or minor releases, and not patches.

Of course, I think Aaron should be free to experiment with whatever approach he likes in his prototype. I think those experiments should occur in a separate module, however.

Thanks David, your solution sounds fine, let me know when it is implemented and documented so I can use it in the KAR system.