ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <ml_ivy-u...@nmhq.net>
Subject Re: dynamically modifying dependency versions during resolve
Date Fri, 27 Jun 2008 03:03:23 GMT
On Thu 2008-06-26 at 20:48h, Shawn Castrianni wrote on ivy-user:
> I guess I will give up after this email because I am not getting my point across as to
why I need this.  I will answer one of your questions and leave it at that.
> 
> > What I wonder here is: After you've tested C2 with A and published
> > it to the public repository, how can that testing be put to use?
> > Builds of A or dependencies on A will still get the old C1, *unless*
> > a dependency on C2 is specified somewhere by some module. Then why
> > should the testing be able to do without specifiying that dependency?
> 
> If C contains interfaces and A contains implementations of those
> interfaces, I want to make sure my interface changes in C do not
> break the build of A before I checkin my changes to C.

Well, a build of A will only get these interface changes if the
dependency of B to C changes, right? Which means that this won't
happen unless and until there's a new revision of B. If there is to be
a new revision of B now depending on the new C, the new C will also
have to be tested with the new B. So why can't the test of A wait
until that new revision of B, without which there can't be any build
of A that would break due to the new C?
And given a new revision of B, A has to be tested against that anyway,
so you can simply test against C at the same time in one go.

Depending on whether the maintainer of B and C is the same or not,
we handle such cases by testing B with C and then A with B and C by
either publishing B and C locally (same maintainer) or publishing
in the shared repository but with status=testing (different
maintainers). An alternative to the latter would be to publish to a
shared "testing" repository which is chained between the local and the
regular shared repository.

[...]
> I can't believe Ernest Pasour and myself are the only ones needing this behavior.

If I understand you correctly, you would want the newest revision of
*any* transitive dependency. This is something I certainly wouldn't want,
as bumping up all dependencies throughout the dependency tree can have
all sorts of effects and cause breakage for reasons totally unrelated
to what actually needs to be tested. I would only want to update the
dependencies for what I plan to transitively depend on (C, in the
above case), and that means specifying somewhere in test build
environment of A that a newer revision of (specifically) C should be
used. And this is nothing different than a build dependency of A on C.
One can use a dedicated "testbuild" conf to play safe.

-- Niklas Matthies

Mime
View raw message