Use-cases for version ranges?

[Stuart McCulloch]

On 20 Nov 2011, at 16:53, 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).
> 
> 2. Regardless of the author recommendations, end-users should be able to
> override the recommendations and use whatever version they wish.

I don't know, it just seems like a lot of work compared with following a simple standard. Just like if everyone chose their own symbols for mathematics; yes it would be flexible and people could share their symbol documents (and change them over time), but it makes interpreting the data and building systems on top much more work, especially when you have modules following radically different schemes. As a deployer I'd have to find the right 
compatibility listings and interpret them, whereas with a standard version scheme I can simply apply existing knowledge. Note that even just agreeing on the meaning of the major/minor/micro segments and allowing some customization at the qualifier level for specific tags (alpha, beta, etc.) would be a start.

--
Cheers, Stuart

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