I'm trying to clarify some thoughts in my own mind about how different kinds of backwards compatibility interact with different kinds of version numbering.
There are at least two dimensions of backwards compatibility of relevance: binary v. source, and provider v. consumer. Not all combinations are important to OSGI , but there do to seem to be some situations where different use types suggest different potential version numbers (rather than ranges). 1. Source compatible but binary incompatible changes. In Java, the most commonly discussed changes of this kind are specializing a method return types (e.g. Collection<String> => List<String>). I Under standard Java linkage rules, this will cause the methods to have different signatures, making them incompatible, and requiring a major version change. Older source can be compiled against the newer library without changes, either to the source code, or a hypothetical range of return specialized (RS) versions ; if the source were changed to use the more specialized return type, it would require the increasing the minimum RS version number. Thus, only a minor RS bump is required. Where this becomes interesting is if an OSGI framework is extended to be able to rewrite calls from older bundles to use the newer method signature (quasi-recompiling). That would allow the newer package to satisfy more constraints. 2. Provider vs. Consumer : default methods One of the primary use cases for default methods is to allow for new methods to be added to interfaces without requiring changes to existing providers. These might be convenience methods, be optional with reasonable defaults, or be implementable using existing methods, with more performant implementations possible but not mandatory. Early experiments handling default methods in OSGI using micro versions showed that that approach was not viable. A different approach might be to consider changes that only add default methods to be neutral to invisible to an implementation of the previous version of the class (excluding accidental signature clash). To packages calling the new methods there has been a minor increase; similarly for packages that implement one or more of the default methods. It seems to me as if there is a separate conceptual version number is default aware, and that need not have the minor bump required in the primary version number. [I'm getting ready to run analysis over a mostly complete set of all bundles in the index on the ibiblio maven central mirror, which is mostly complete through 11/2016, where a bundle is defined to be any artifact that had a BSN in the manifest when processed by the nexus (now maven) indexer. I may augment this set with output of any PAX wrap: URLs mentioned in Karaf feature files. Some of my primary hypotheses is that the majority of these bundles do not follow semantic versioning rules, and that some, but not all, of the set of importing bundleswill have detectable possible linkage errors (e.g a reference to a removed class or method). A secondary hypotheses is that applying recommended bndlib Baseline renumbering to all (non qualified?) versions in a sequence, mapping external referencing import ranges to the appropriate rebased range will result in a non-trivial set of unsatisfiable dependencies. There are other hypotheses that I'm trying to refine; what I'm hoping to find are indica that can be used to predict more reliable import ranges for given maven artifact sequences, and to identify opportunities for safely relaxing constraints.] Simon
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
