On Tue, Dec 9, 2008 at 11:01 AM, Tom Childers <tom.childers at sun.com> wrote:
>... then links may get changed and cause things to break.
> We asked the team to adopt the convention established for junit, LSARC/
> 2008/633, similar to /usr/lib:
>
> /usr/share/lib/java/junit.jar link to most recent version
> /usr/share/lib/java/junit-4.5.jar
> /usr/share/lib/java/junit-3.8.2.jar
> ...etc.
>
> However, if they place all the findbugs pieces, like
> annotations-1.3.4.jar, in /usr/share/lib/java, then we have the
> situation that multiple projects who require and deliver the same
> component can overwrite each other. annotations.jar could be changed
> to link to a different version, breaking the functionality of
> something that is already installed.
Shouldn't those <somethings> depend directly on the versioned item and
NOT on the convenience link? That is, if I depend on junit, I should either
A) link to /usr/share/lib/java/junit.jar IFF the interface stability
I care about
is Committed,
or
B) link to /usr/share/lib/java/junit-4.5.jar if the interface
stability is less stable
If I link to "junit.jar", but junit's stability is, say, Volatile,
then I have, as they
say, just screwed up. If junit (the convenience link) evolves incompatibly
out from under me, my application breaks immediately. Braap.
Danek Duvall wrote:
> Those links need each to be delivered exactly once on a system, by just one
> package.
+1
I'd add, that package is delivered by the team that "owns" junit, and they
get to decide, based on the promises they made when exporting the
junit interface stability, when and if the convenience link(s) should change.
If they promised "Committed", then they *must* do the diligence to ensure
that the new version of junit contains absolutely no incompatible changes.
If they promised Committed, then I should be able to depend on it being
Committed, and use of the convenience link is safe. Otherwise, for all
of the perturbations of "otherwise", it isn't.
-John
