Use-cases for version ranges?

[cowwoc]

On 22/11/2011 1:54 PM, Lukas Krecan [via jigsaw-dev] wrote:
> > 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).
> > recommends using version 1.1, 1.2, 1.3 (notice this is a list of 
> specific
> 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?

     I think we need to differentiate between compile-time and run-time 
dependencies. I'm saying that developers should be allowed to modify 
version compatibility (used exclusively at run-time) after the fact. 
This information is used in two situations:

1. If there is a version conflict (B depends on A 1.0, C depends on A 
1.1,  D depends on B and C. What version of A does C use at run-time?)
2. If there is a newer version than was used at compile-time.

     In both cases, the system makes recommendations which end-users can 
always override. The builds remain stable and repeatable even if version 
compatibility is modified after the fact.

Gili


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