StabilityOfAPI
From APIDesign
| Line 5: | Line 5: | ||
The trouble is that we live in [[clueless]] world and most of the people (including [[API]] designers) don't have time to fully evaluate negative influence of their changes. When producers of up-stream library make a mistake, there should be a way for the consumers of such [[API]] to recover and shield themselves. From this thought there is just a small step to the idea of giving the users of an [[API]] right to classify [[netbeans:API Stability|stability]] of the [[API]] they use. Here the [[RangeDependenciesAnalysed|range dependencies]] come into the play. | The trouble is that we live in [[clueless]] world and most of the people (including [[API]] designers) don't have time to fully evaluate negative influence of their changes. When producers of up-stream library make a mistake, there should be a way for the consumers of such [[API]] to recover and shield themselves. From this thought there is just a small step to the idea of giving the users of an [[API]] right to classify [[netbeans:API Stability|stability]] of the [[API]] they use. Here the [[RangeDependenciesAnalysed|range dependencies]] come into the play. | ||
| - | Should there be a repository of modules and their [[dependencies]] including module <math>M</math> in versions <math>1.1, 1.2, 1.5, 2.0, 2.5, 3.0</math>. If majority of other modules having a dependency on <math>M</math> uses range <math>[1.1,2.0)</math> (e.g. the classical range for [[semantic versioning]]), then we can deduce that the owner of module <math>M</math> is doing good job keeping [[BackwardCompatibility]]. If many dependencies on <math>M</math> use for example <math>[1.1,1.5)</math>, then we can deduce that something unnatural (from the point of [[semantic versioning]] happened in version <math>1.5</math>) and that the owner of the module <math>M</math> underestimated the impact of changes in version <math>1.5</math>. On the other hand, if many dependencies on <math>M</math> use range like <math>[1.1,3.0)</math> then the incompatible change was probably not as incompatible as it might have seen. | + | Should there be a repository of modules and their [[dependencies]] including module <math>M</math> in versions <math>1.1, 1.2, 1.5, 2.0, 2.5, 3.0</math>. If majority of other modules having a dependency on <math>M</math> uses range <math>[1.1,2.0)</math> (e.g. the classical range for [[semantic versioning]]), then we can deduce that the owner of module <math>M</math> is doing good job keeping [[BackwardCompatibility]]. If many dependencies on <math>M</math> use for example <math>[1.1,1.5)</math>, then we can deduce that something unnatural (from the point of [[semantic versioning]] happened in version <math>1.5</math>) and that the owner of the module <math>M</math> underestimated the impact of changes in version <math>1.5</math>. On the other hand, if many dependencies on <math>M</math> use range like <math>[1.1,3.0)</math> then the [[incompatible]] change was probably not as [[incompatible]] as it might have seen. |
The beauty of analysing the overall dependencies on a module is that it clearly expresses the statistical probability of [[BackwardCompatibility]] as seen by all users. It also allows the users to '' be sure application really runs as expected'' if the dependency is satisfied. Of course, the author of such [[API]] should set the expectations up by using [[netbeans:API Stability|stability category]], but the ultimate decision remains in the hands of the [[API]] users. | The beauty of analysing the overall dependencies on a module is that it clearly expresses the statistical probability of [[BackwardCompatibility]] as seen by all users. It also allows the users to '' be sure application really runs as expected'' if the dependency is satisfied. Of course, the author of such [[API]] should set the expectations up by using [[netbeans:API Stability|stability category]], but the ultimate decision remains in the hands of the [[API]] users. | ||
Current revision
How one specifies how stable just published API is? The semantic versioning suggests to treat all releases up to changed major version (e.g. up to 2.0.0) as being BinaryCompatible. The NetBeans API Stability proposal allows each API to be attributed as stable, devel or private. The netbeans:NbmPackageStability goes even further and suggests to use different ranges for different stability of the API. Is this the right approach?
In ideal, rationalistic world, it is. Under the assumption that API designers are rationalistic and understand the versioning issues and the importance of proper dependency management, it is fine to expect that they will do everything to follow principles of semantic versioning (or netbeans:NbmPackageStability guidelines) and either keep BackwardCompatibility or bump the major version. In rationalistic world, it is enough to believe our application will sort of work and at least link and the rest will be achieved by the good work of the other, rationalistic people.
The trouble is that we live in clueless world and most of the people (including API designers) don't have time to fully evaluate negative influence of their changes. When producers of up-stream library make a mistake, there should be a way for the consumers of such API to recover and shield themselves. From this thought there is just a small step to the idea of giving the users of an API right to classify stability of the API they use. Here the range dependencies come into the play.
Should there be a repository of modules and their dependencies including module M in versions 1.1,1.2,1.5,2.0,2.5,3.0. If majority of other modules having a dependency on M uses range [1.1,2.0) (e.g. the classical range for semantic versioning), then we can deduce that the owner of module M is doing good job keeping BackwardCompatibility. If many dependencies on M use for example [1.1,1.5), then we can deduce that something unnatural (from the point of semantic versioning happened in version 1.5) and that the owner of the module M underestimated the impact of changes in version 1.5. On the other hand, if many dependencies on M use range like [1.1,3.0) then the incompatible change was probably not as incompatible as it might have seen.
The beauty of analysing the overall dependencies on a module is that it clearly expresses the statistical probability of BackwardCompatibility as seen by all users. It also allows the users to be sure application really runs as expected if the dependency is satisfied. Of course, the author of such API should set the expectations up by using stability category, but the ultimate decision remains in the hands of the API users.
Follow
