TransitivityOfIncompatibleChange

From APIDesign

Happens when reusing APIs provided by others as described in Chapter 10. However TransitivityOfIncompatibleChange is only meaningful when using semantic versioning - in case of general RangeDependencies, it looses its meaning.

Transitivity in Semantic World

Imagine you have a module M@1.0 which re-exports APIs provided by module N@1.0. The re-exported APIs of module N become part of the API of module M as they may be visible in M's own class signatures as parameter or return types, etc.

Let's now continue by showing envisioning that the author of module N decides to release new, incompatible version. According to rules of semantic versioning the version should have different major version - e.g. let it be called N@2.0.

Often, the producer of module M would like to run on the most recent version of module N. As such it may consider creating new version of own module which would depend on N@2.0. Can this version be called M@1.1? Well, if we allow it to be called M@1.1, then:

1. we run into NP-Complete problems as the LibraryReExportIsNPComplete proof shows
2. we go against the motto of semantic versioning

The interface of N are re-exported and thus basically part of the public signatures of M. As there was an incompatible change in these interfaces, semantic versioning urges us to increment the major version of module M. The incompatible change in N transitively influences M. Its author should release M@2.0!

When Things Go Relative

Needs to be eliminated by proper dependencies versioning. Quite complicated by use of RangeDependencies.

TBD.