Hi Zac,
thanks for the reply, and apologies for the delayed response.
Your ideas are all good ones in general but unfortunately not quite what we
want. I'm not in a position to dictate version numbering policies to teams,
nor are they always free to choose, which rules out your points 1 and 3. Even
if I were, something like semantic versioning only says what you intended to be
true, not what's actually true. Released versions which turned out to be
unexpectedly incompatible or unsafe could be blacklisted somehow, but I think
we'd rather explicitly whitelist things. (Hmm, actually ... having the
dependencies externalised as (empty) modules themselves allows you to release a
new version of the dependency which marks that combination as blacklisted.
Interesting ...)
Your point 2 is sort of what I'm proposing, but I'm suggesting having a single
module which does this forcing, rather than repeating the forcing in all
modules which use A and B. That is, instead of {X:1.0, Y:1.1, Z:2.3} -> {A:1,
B:2}, have {X:1.0, Y:1.1, Z:2.3} -> {A_1_B_2:1.0} -> {A:1, B:2}. This not only
reduces duplication, but allows the team publishing A to also publish the
approved set of module combinations, so that it's clear to other teams what to
trust.
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.
-----Original Message-----
From: Zac Jacobson [mailto:pie....@gmail.com]
Sent: 29 September 2014 06:46
To: ivy-user@ant.apache.org
Subject: Re: Ways to state "forward compatibility" after the fact
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
> ______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
