StabilityOfAPI - Revision history

JaroslavTulach at 01:48, 7 November 2012

JaroslavTulach — Wed, 07 Nov 2012 01:48:06 GMT

←Older revision		Revision as of 01:48, 7 November 2012
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.

JaroslavTulach at 01:47, 7 November 2012

JaroslavTulach — Wed, 07 Nov 2012 01:47:00 GMT

←Older revision		Revision as of 01:47, 7 November 2012
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.

JaroslavTulach: New page: 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 [[BinaryCompatibl...

JaroslavTulach — Wed, 07 Nov 2012 01:22:34 GMT

New page: 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 [[BinaryCompatibl...

New page

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|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 [[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.

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.