TransitivityOfIncompatibleChange
From APIDesign
(→Transitivity in Semantic World) |
|||
| Line 11: | Line 11: | ||
# we go against the motto of [[semantic versioning]] | # 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''! | + | 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'' [[TransitivityOfIncompatibleChange|transitively]] influences ''M''. Its author should release ''M@2.0''! |
== When Things Go Relative == | == When Things Go Relative == | ||
Revision as of 01:16, 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
