You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by "Greene, Hugh" <HG...@tmvse.com> on 2014/09/26 12:23:39 UTC
Ways to state "forward compatibility" after the fact
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:hgreene@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
______________________________________________________________________
RE: Ways to state "forward compatibility" after the fact
Posted by "Greene, Hugh" <HG...@tmvse.com>.
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:hgreene@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.fed@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 <HG...@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:hgreene@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
______________________________________________________________________
Re: Ways to state "forward compatibility" after the fact
Posted by Zac Jacobson <pi...@gmail.com>.
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 <HG...@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:hgreene@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
> ______________________________________________________________________