Semantic Versioning in OSGi is about binary compatibility and not source compatibility.
Adding a default method to an interface is always a minor version increment. For provider type interfaces, the consumer can depend upon the new method and must declare that by requiring the higher minor version. For consumer type interfaces, the consumer does not have to implement the default method, so it is not a major version change but the provider can depend upon the new method and must declare that by requiring the higher minor version. A micro version bump is insufficient as there is a new API which API users can depend upon being available.
--
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
[email protected]
BJ Hargrave
Senior Technical Staff Member, IBM // office: +1 386 848 1781
OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
[email protected]
----- Original message -----
From: Simon Spero <[email protected]>
Sent by: [email protected]
To: OSGi Developer Mail List <[email protected]>
Cc:
Subject: [osgi-dev] Different conceptual version numbers for different forms of backwards compatibility?
Date: Wed, May 3, 2017 6:45 PM
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>). IUnder 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 methodsOne 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
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
