ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greene, Hugh" <HGre...@tmvse.com>
Subject RE: Ways to state "forward compatibility" after the fact
Date Tue, 14 Oct 2014 09:38:22 GMT
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 <HGreene@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
______________________________________________________________________
Mime
View raw message