Use-cases for version ranges?

[cowwoc]

Stuart McCulloch wrote:
> 
> 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].
> 

He can, but what I prefer about the mechanism I raised above is that you can
achieve the same functionality without locking down the versioning scheme.
Each publisher specifies a list of versions (not version ranges) the new
release is compatible with. Thanks to transitivity the list of versions only
needs to contain one version for the system will figure out the rest. Here
is a simple example:

I publish Log4j version 1.1 and specify it is compatible with version 1.0
I publish Log4j version 1.2 and specify it is compatible with version 1.1
I publish Log4j version 1.3 and specify it is compatible with version 1.2
I publish Log4j version 1.4 and specify it is compatible with version 1.3

Someone depends on log4j 1.1. By transitivity, this means the log4j author
recommends using version 1.1, 1.2, 1.3 (notice this is a list of specific
versions, not a version range).

In order to address the issue brought up by Lukas ("Some changes can cause
problems
that can not be envisaged  by their author") I'd like to add two caveats to
complete the picture:

1. Authors are able to change the compatibility listings after-the-fact. Say
I published log4j 1.3, declared it was compatible with 1.2 but found a
compatibility problem after-the-fact. I'd have to update version 1.3's
meta-data (remove its compatibility with 1.2) and version 1.4's meta-data
(change its compatibility from 1.3 to 1.2).

2. Regardless of the author recommendations, end-users should be able to
override the recommendations and use whatever version they wish.


Stuart McCulloch wrote:
> 
>> 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.
> 

He seems to agree with my point "the exporter of a package knows exactly to
which version he is compatible, being the responsible person for that
package [...] The importer is almost always guessing."


Stuart McCulloch wrote:
> 
> 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
> 

Nice. I didn't know that.

Thanks,
Gili

--
View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Use-cases-for-version-ranges-tp5002801p5008437.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.