Hi Simon, On Wed, May 3, 2017 at 10:46 PM, Simon Spero <sesunc...@gmail.com> wrote: > 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.
Not to detract from your main point, but method return types are not part of the method's signature in Java. https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.4.2 Robert > > 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 -- http://robert.muntea.nu/ _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
