module dependencies issues

[Chris Angelico]

On Fri, Jul 10, 2015 at 6:36 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
> Chris Angelico <rosuav at gmail.com>:
>
>> How do you expect the end result to work? Will it be that your code
>> imports one version of a module, but other code imports another? You
>> would have to rename one of them or something.
>
> At work, we have created an analogous component system that has solved
> this issue the way I think it should be solved.
>
> Component B ver 1.1 must declare (ABI) backward-compatibility with B ver
> 1.0. That allows the component system to resolve such natural dependency
> discrepancies in a safe manner.
>
> The application (or component) C, which was created at B ver 1.0 time,
> can't depend on >= B-1.0 because C has no way of knowing if, say, B-2.0
> will be backward-compatible with B-1.0. The compatibility declaration
> belongs to B.

Or, B could simply declare that it follows the common versioning
pattern of Major.Minor.Revision, where Revision changes don't add
features or in any way break compatibility (or if they do, it's a
bug), Minor changes add features without normally breaking backward
compatibility in any serious way, and Major chances might break all
sorts of things (but usually won't). Then, depending on B >= 1.3 < 2.0
is sufficient if you require a feature that came in with 1.3. If it
turns out that 1.7 breaks your code, you either change your code to be
compatible with 1.7 (and either drop support for 1.3 or figure out
some way of supporting both), or declare B >= 1.3 < 1.7. It's really
not difficult. This is what version numbers are for.

In general, I would expect that B 1.1 is backward-compatible with B
1.0, unless otherwise stated. Why must it be declared in any way other
than the version number?

ChrisA