Use-cases for version ranges?
cowwoc at bbs.darktech.org
Tue Nov 22 19:07:37 PST 2011
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
> > (change its compatibility from 1.3 to 1.2).
> > recommends using version 1.1, 1.2, 1.3 (notice this is a list of
> 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.
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.
More information about the jigsaw-dev