Hi Hugh, I have a few thoughts to share with you:
1. You could give an upper bound on the version of B upon which A relies, indicating that A 1.0 needs at most B 1.7: see the version range matchers. http://ant.apache.org/ivy/history/2.1.0/settings/version-matchers.html 2. You could use the ivy file of whatever module it is that is relying on A to also rely on a particular version of B, using the force attribute of the dependency to get the version you want. 3. You should have a reasonable versioning scheme. eg http://semver.org/ You could consider publishing a minor update to A with the new dependency on B when you have tested and shown that the A codebase works with that new, updated B, even if there's no other change to A. Hope that gives you some ideas. Zac On Fri, Sep 26, 2014 at 3:23 AM, Greene, Hugh <hgre...@tmvse.com> wrote: > Hi again, all, > > I have another question about unusual ways to state dependencies. We have > a situation where module A depends on module B, and B changes more often > than A. After some releases of B, we would like to be able to test it with > existing released versions of A, then somehow state that existing version > A:1.0-which was published as compatible with B:1.3, say-is also compatible > with B:2.7. We want to use strict version checking, rather than the > typical behaviour of "just pick the latest version and hope for the best", > or even "A:1.0 depends on B:1.+", because we only want to allow > combinations which have been tested, for safety reasons. > > I don't want to do this by publishing a modified version of the ivy.xml > for A:1 because, well, it's a release, so it shouldn't change later. > (Also, we're using Artifactory across multiple sites, and its caching of > release versions-identified by path pattern-is smart in that it never > bothers checking the originating server for changes.) > > The only approach I've come up with that could work is an awkward one of > externalising the version part of the dependencies. This would involve the > following module versions, created in the following order over time. > > * B:1.3 > > * A:1.0, depending on B:+ > > * A_depends_on_B:1.0-1.3, depending on A:1.0 and B:1.3 > > * B:2.7 > > * A_depends_on_B:1.0-2.7, depending on A:1.0 and B:2.7 > > We would require people to depend on A, B, and A_depends_on_B, each with > non-floating versions. I'm fairly sure I could add a custom Gradle > resolution rule to enforce this way of doing things. > > But, all that sounds quite painful and doesn't fit the usual way of doing > things. Does anyone have any other suggestions? > > Regards, > > Hugh Greene, Senior Software Developer > Toshiba Medical Visualization Systems Europe, Ltd > Bonnington Bond, 2 Anderson Place, Edinburgh EH6 5NP, UK > Tel + 44 (0)131 472 4792 / Fax + 44 (0) 131 472 4799 > http://www.tmvse.com / mailto:hgre...@tmvse.com > > DISCLAIMER > Unless indicated otherwise, the information contained in this message is > privileged and confidential, and is intended only for the use of the > addressee(s) named above and others who have been specifically authorized > to receive it. If you are not the intended recipient, you are hereby > notified that any dissemination, distribution or copying of this message > and/or attachments is strictly prohibited. The company accepts no liability > for any damage caused by any virus transmitted by this email. Furthermore, > the company does not warrant a proper and complete transmission of this > information, nor does it accept liability for any delays. If you have > received this message in error, please contact the sender and delete the > message. > > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________
