JaroslavTulach: /* Implications */ - 2014-01-22 08:24:20

Implications

←Older revision Revision as of 08:24, 22 January 2014
Line 77: Line 77:
The stability of an [[API]] in ''complete range repository'' is ultimately decided by users of the [[API]]. In case the [[API]] remains compatible for many versions, the dependency ranges on such [[API]] will be wider.
The stability of an [[API]] in ''complete range repository'' is ultimately decided by users of the [[API]]. In case the [[API]] remains compatible for many versions, the dependency ranges on such [[API]] will be wider.
-
For end user application modules it is OK if they use narrow dependency ranges on dependent [[API]]s. When one controls the whole deployment, there is no problem using even ''equality range'' (like <math>[1.3, 1.3]</math>) - quality assurance departments love when they can test the final application only in a single configuration of modules.
+
For end user application modules it is OK if they use narrow dependency ranges on dependent [[API]]s. When one controls the whole deployment, there is no problem using even ''equality range'' (like '''[1.3, 1.3]''') - quality assurance departments love when they can test the final application only in a single configuration of modules.
For a widely used [[API]] narrow ranges form a problem. They tight together the [[API]] with the others basically prescribing everyone what dependencies one has to have on all of the [[API]]s taking freedom from the [[API]] users. Flexibility is needed when producing a framework.
For a widely used [[API]] narrow ranges form a problem. They tight together the [[API]] with the others basically prescribing everyone what dependencies one has to have on all of the [[API]]s taking freedom from the [[API]] users. Flexibility is needed when producing a framework.
Some kind of future expectations should be provided by the library vendors (in form of [[semantic versioning]] or [[netbeans:API Stability|stability classification]]) and for many purposes users can rely on such future defined open range. On the other hand, when something goes wrong, narrowing the range returns the control over versioning to hands of the [[API]] users.
Some kind of future expectations should be provided by the library vendors (in form of [[semantic versioning]] or [[netbeans:API Stability|stability classification]]) and for many purposes users can rely on such future defined open range. On the other hand, when something goes wrong, narrowing the range returns the control over versioning to hands of the [[API]] users.

JaroslavTulach: /* Implications */ - 2014-01-22 08:21:28

Implications

←Older revision Revision as of 08:21, 22 January 2014
Line 75: Line 75:
== Implications ==
== Implications ==
-
The stability of an [[API]] in ''complete range repository'' is ultimately decided by users of the [[API]]. In case the [[API]] remains compatible for many versions, the dependency ranges on a the [[API]] will be wider.
+
The stability of an [[API]] in ''complete range repository'' is ultimately decided by users of the [[API]]. In case the [[API]] remains compatible for many versions, the dependency ranges on such [[API]] will be wider.
-
For end user application modules it is OK if it is using narrow dependency ranges on [[API]]s. For a widely used [[API]] this may be a problem. Narrow range tights together the [[API]] with the others basically prescribing everyone what dependencies one has to have on all of the [[API]] taking freedom from the [[API]] users.
+
For end user application modules it is OK if they use narrow dependency ranges on dependent [[API]]s. When one controls the whole deployment, there is no problem using even ''equality range'' (like <math>[1.3, 1.3]</math>) - quality assurance departments love when they can test the final application only in a single configuration of modules.
 +
 
 +
For a widely used [[API]] narrow ranges form a problem. They tight together the [[API]] with the others basically prescribing everyone what dependencies one has to have on all of the [[API]]s taking freedom from the [[API]] users. Flexibility is needed when producing a framework.
Some kind of future expectations should be provided by the library vendors (in form of [[semantic versioning]] or [[netbeans:API Stability|stability classification]]) and for many purposes users can rely on such future defined open range. On the other hand, when something goes wrong, narrowing the range returns the control over versioning to hands of the [[API]] users.
Some kind of future expectations should be provided by the library vendors (in form of [[semantic versioning]] or [[netbeans:API Stability|stability classification]]) and for many purposes users can rely on such future defined open range. On the other hand, when something goes wrong, narrowing the range returns the control over versioning to hands of the [[API]] users.

JaroslavTulach at 01:20, 7 November 2012 - 2012-11-07 01:20:40

←Older revision Revision as of 01:20, 7 November 2012
Line 33: Line 33:
The latter, paranoiac approach, is likely to be used more often in end user applications. The first, optimistic one, seems more suitable for reusable libraries.
The latter, paranoiac approach, is likely to be used more often in end user applications. The first, optimistic one, seems more suitable for reusable libraries.
-
== Stability of Published [[API]] ==
+
== [[StabilityOfAPI|Stability]] of Published [[API]] ==
-
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?
+
{{:StabilityOfAPI}}
-
 
+
-
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.
+
-
 
+
-
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.
+
== Getting trapped by [[RangeDependenciesNP|NP-Completeness]] ==
== Getting trapped by [[RangeDependenciesNP|NP-Completeness]] ==

JaroslavTulach: /* Implications */ - 2012-01-08 16:38:36

Implications

←Older revision Revision as of 16:38, 8 January 2012
Line 83: Line 83:
== Implications ==
== Implications ==
-
The stability of an [[API]] in ''complete range repository'' is defined by users of the [[API]]. In case the [[API]] remains compatible for many versions, the dependency ranges on a the [[API]] will be wider.
+
The stability of an [[API]] in ''complete range repository'' is ultimately decided by users of the [[API]]. In case the [[API]] remains compatible for many versions, the dependency ranges on a the [[API]] will be wider.
For end user application modules it is OK if it is using narrow dependency ranges on [[API]]s. For a widely used [[API]] this may be a problem. Narrow range tights together the [[API]] with the others basically prescribing everyone what dependencies one has to have on all of the [[API]] taking freedom from the [[API]] users.
For end user application modules it is OK if it is using narrow dependency ranges on [[API]]s. For a widely used [[API]] this may be a problem. Narrow range tights together the [[API]] with the others basically prescribing everyone what dependencies one has to have on all of the [[API]] taking freedom from the [[API]] users.
 +
 +
Some kind of future expectations should be provided by the library vendors (in form of [[semantic versioning]] or [[netbeans:API Stability|stability classification]]) and for many purposes users can rely on such future defined open range. On the other hand, when something goes wrong, narrowing the range returns the control over versioning to hands of the [[API]] users.

JaroslavTulach: /* Upper bound */ - 2012-01-08 16:34:46

Upper bound

←Older revision Revision as of 16:34, 8 January 2012
Line 20: Line 20:
* ''Know'' can mean to ''be sure''. E.g. we have verified that we really work with that version. We have downloaded that version of a library, executed all our tests and certified it. We really checked our application works with that version. In some situations this kind of ''knowledge'' is required.
* ''Know'' can mean to ''be sure''. E.g. we have verified that we really work with that version. We have downloaded that version of a library, executed all our tests and certified it. We really checked our application works with that version. In some situations this kind of ''knowledge'' is required.
-
* ''Know'' can however mean to ''believe''. Often we can trust the producer of the library, that they will conform to some versioning scheme (like [[Semantic versioning]]) and based on such trust we can estimate the [[upper bound]].
+
* ''Know'' can however mean to ''believe''. Often we can trust the producer of the library, that they will conform to some versioning scheme (like [[Semantic versioning]]) and based on such trust we can estimate the [[upper bound]] (even sooner than the newer versions of that library are produced).
What does it mean to ''work''?
What does it mean to ''work''?

JaroslavTulach: /* Lower Bound */ - 2012-01-08 16:33:10

Lower Bound

←Older revision Revision as of 16:33, 8 January 2012
Line 9: Line 9:
Each [[dependency]] has a lower bound, a minimal required version of a library that we can work against. When producing our application, it is in our interest to verify that we can really compile and create our application against the ''lower bound''. The easiest way to ensure we are using only classes and methods available in such ''lower bound'' version is to compile against the ''lower bound'' version of each library we define a [[dependency]] on.
Each [[dependency]] has a lower bound, a minimal required version of a library that we can work against. When producing our application, it is in our interest to verify that we can really compile and create our application against the ''lower bound''. The easiest way to ensure we are using only classes and methods available in such ''lower bound'' version is to compile against the ''lower bound'' version of each library we define a [[dependency]] on.
-
Or from the opposite perspective: Compiling against newer version than the ''lower bound'' is too errorprone. [[NetBeans]] allows this and especially during development cycle, when things are changing rapidly, this often leads to {{JDK|java/lang|LinkageError}}s that render the whole application unusable at random and unexpected moments.
+
Or from the opposite perspective: Compiling against newer version than the ''lower bound'' is too errorprone. [[NetBeans]] allows this during development cycle, when things are changing rapidly, this often leads to {{JDK|java/lang|LinkageError}}s that render the whole application unusable at random and unexpected moments.
''Lower bound'' is the version that we compile against.
''Lower bound'' is the version that we compile against.

JaroslavTulach: /* Lower Bound */ - 2012-01-08 16:32:31

Lower Bound

←Older revision Revision as of 16:32, 8 January 2012
Line 7: Line 7:
== Lower Bound ==
== Lower Bound ==
-
Each [[dependency]] has a lower bound, a minimal required version of a library that we can work against. When producing our application, it is in our interest to verify that we can really compile and create our application against the ''lower bound''. The easiest way to ensure we are using only classes and methods available in such ''lower bound'' version is to compile against the ''lower bound'' version of each library we define a dependency on.
+
Each [[dependency]] has a lower bound, a minimal required version of a library that we can work against. When producing our application, it is in our interest to verify that we can really compile and create our application against the ''lower bound''. The easiest way to ensure we are using only classes and methods available in such ''lower bound'' version is to compile against the ''lower bound'' version of each library we define a [[dependency]] on.
Or from the opposite perspective: Compiling against newer version than the ''lower bound'' is too errorprone. [[NetBeans]] allows this and especially during development cycle, when things are changing rapidly, this often leads to {{JDK|java/lang|LinkageError}}s that render the whole application unusable at random and unexpected moments.
Or from the opposite perspective: Compiling against newer version than the ''lower bound'' is too errorprone. [[NetBeans]] allows this and especially during development cycle, when things are changing rapidly, this often leads to {{JDK|java/lang|LinkageError}}s that render the whole application unusable at random and unexpected moments.

JaroslavTulach at 16:31, 8 January 2012 - 2012-01-08 16:31:48

←Older revision Revision as of 16:31, 8 January 2012
Line 3: Line 3:
When [[RangeDependenciesAnalysed|analysing dependencies]] it can be easily proven that [[RangeDependencies]] (as used by [[OSGi]]) are too flexible and may lead to [[NP-Complete]] problems. However recently I started to ask following question - it is known that [[LibraryReExportIsNPComplete|module configuration problem]] can be fixed by generating so called [[LibraryWithoutImplicitExportIsPolynomial|complete repositories]]. Can't the same trick be applied to repositories using [[RangeDependencies]] as well?
When [[RangeDependenciesAnalysed|analysing dependencies]] it can be easily proven that [[RangeDependencies]] (as used by [[OSGi]]) are too flexible and may lead to [[NP-Complete]] problems. However recently I started to ask following question - it is known that [[LibraryReExportIsNPComplete|module configuration problem]] can be fixed by generating so called [[LibraryWithoutImplicitExportIsPolynomial|complete repositories]]. Can't the same trick be applied to repositories using [[RangeDependencies]] as well?
-
My current feeling is that it can. This page is my attempt to formalize the feeling to something more formal.
+
My current feeling is that it can. This page is my attempt to formalize that feeling.
== Lower Bound ==
== Lower Bound ==

JaroslavTulach at 16:31, 8 January 2012 - 2012-01-08 16:31:14

←Older revision Revision as of 16:31, 8 January 2012
Line 1: Line 1:
<skin>monobook</skin>
<skin>monobook</skin>
-
When [[RangeDependenciesAnalysed|analysing dependencies]] it can be easily proven that [[RangeDependencies]] (as used by [[OSGi]]) are too flexible and may lead to [[NP-Complete]] problems. However recently I started to ask following question - it is known that [[LibraryReExportIsNPComplete]] and that the problem can be fixed by generating so called [[LibraryWithoutImplicitExportIsPolynomial|complete repositories]]. Can't the same trick be applied to repositories using [[RangeDependencies]] as well?
+
When [[RangeDependenciesAnalysed|analysing dependencies]] it can be easily proven that [[RangeDependencies]] (as used by [[OSGi]]) are too flexible and may lead to [[NP-Complete]] problems. However recently I started to ask following question - it is known that [[LibraryReExportIsNPComplete|module configuration problem]] can be fixed by generating so called [[LibraryWithoutImplicitExportIsPolynomial|complete repositories]]. Can't the same trick be applied to repositories using [[RangeDependencies]] as well?
My current feeling is that it can. This page is my attempt to formalize the feeling to something more formal.
My current feeling is that it can. This page is my attempt to formalize the feeling to something more formal.

JaroslavTulach at 14:07, 8 January 2012 - 2012-01-08 14:07:27

←Older revision Revision as of 14:07, 8 January 2012
Line 80: Line 80:
Obviously this kind of computation can be done in polynomial time. Thus we can perform this check during every compilation. When we have new configuration, we just need to seek the repository and find out if for each module in the configuration we have an existing version of the module that we can compile against. If such version is found, it will be used as a ''lower bound'' for the newly compiled module. The ''upper bound'' will be the inferred one, unless the compiled module restricts it.
Obviously this kind of computation can be done in polynomial time. Thus we can perform this check during every compilation. When we have new configuration, we just need to seek the repository and find out if for each module in the configuration we have an existing version of the module that we can compile against. If such version is found, it will be used as a ''lower bound'' for the newly compiled module. The ''upper bound'' will be the inferred one, unless the compiled module restricts it.
 +
 +
== Implications ==
 +
 +
The stability of an [[API]] in ''complete range repository'' is defined by users of the [[API]]. In case the [[API]] remains compatible for many versions, the dependency ranges on a the [[API]] will be wider.
 +
 +
For end user application modules it is OK if it is using narrow dependency ranges on [[API]]s. For a widely used [[API]] this may be a problem. Narrow range tights together the [[API]] with the others basically prescribing everyone what dependencies one has to have on all of the [[API]] taking freedom from the [[API]] users.