Ordering of versions

[cowwoc]

On 14/11/2011 11:21 AM, Stuart McCulloch [via jigsaw-dev] wrote:
> On 14 Nov 2011, at 16:04, Brian Pontarelli wrote:
>
> > It seems to me that the version scheme for a single module only 
> impacts that module and not its dependencies. When the dependency 
> graph is completely built and then traversed, modules are compared 
> based on their scheme with all the other instances of themselves in 
> the graph. Therefore, I don't think it impacts others at all.
> >
> > Thoughts?
>
> What happens if someone changes the Comparator<Version> implementation 
> used in their module over time? (either by design or mistake)
>
> You could end up with some situations where the ordering was not 
> defined, or there were conflicting/ambiguous results.

     That's true for any implementation of Comparator that already 
exists today. Should we throw out the Comparator interface because 
people could implement it wrong? If a developer pushes a bad Comparator 
implementation, he will simply fix the bug and push the new revision.

> The other downside of an executable versioning scheme is that you 
> probably would have to download a full bundle (maybe with all its 
> dependencies) in order to run its comparison method, only to find out 
> that you didn't actually need that version.

     I don't think any of us are advocating this. The idea would be for 
the version comparator to play a similar role to pom.xml in Maven. You'd 
download the Comparator independently of the module and only proceed if 
you desire that version. I don't see why a Comparator would need to 
depend on other classes in the Module anyway. We're talking about a 
simple String comparison here.

> Executable schemes also make it harder to do static analysis in other 
> languages and could introduce security issues (since you're running 
> unknown code even before installing the bundle).

     Regarding static analysis, as I mentioned in other posts you could 
simply mention that results are cached so the Comparator must be 
deterministic.

     Regarding running untrusted code, the way I see it you're 
downloading a module with the intent of running it. Whether you run 
untrusted code at dependency-resolution time or at runtime makes little 
difference. Either way you are expected to verify that you only run code 
that you trust. When you install a native application on Windows you get 
a warning before the installer even launches (because you don't 
necessarily trust the installer). We'd do the same thing (for any 
untrusted dependency).

Gili


--
View this message in context: http://jigsaw-dev.1059479.n5.nabble.com/Ordering-of-versions-tp4970773p4991902.html
Sent from the jigsaw-dev mailing list archive at Nabble.com.