Use-cases for version ranges?

[Lukas Krecan]

On 11/20/2011 05:53 PM, cowwoc wrote:
> 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).
Sorry, this is really dangerous. We need stable and repeatable builds. 
It implies, that once a module is released, it can never ever be 
changed. Ever. If we change the dependency tree "after-the-fact" we have 
effectively changed all depending applications. Imagine that you have 
perfectly working well tested application and suddenly its behavior 
changes. Why. Because someone out of your control changed the 
compatibility listing. We do not want that, do we?
> 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.