TransitivityOfIncompatibleChange
From APIDesign
| Line 1: | Line 1: | ||
| - | Happens when reusing [[API]]s provided by others as described in [[Chapter 10]]. Needs to be eliminated by proper [[dependencies]] versioning. Quite complicated by use of [[RangeDependencies]]. | + | Happens when reusing [[API]]s 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 [[API]]s provided by module ''N@1.0''. The re-exported [[API]]s 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: | ||
| + | # we run into [[NP-Complete]] problems as the [[LibraryReExportIsNPComplete]] proof shows | ||
| + | # 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]]. | [[TBD]]. | ||
Revision as of 01:14, 7 November 2012
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:
- we run into NP-Complete problems as the LibraryReExportIsNPComplete proof shows
- 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.
Follow
