Hi, Am 22.03.2012 um 15:00 schrieb Marcel Offermans:
>>>>> AFAICT the new spec is backwards compatible. As long as you don't use new >>>>> functionality, nothing changes. >>>>> >>>> >>>> Probably true. The reason we went for the backport instead of using >>>> the snapshot (besides maven release constraints) is that it, for >>>> obvious reasons, does an import for org.osgi.services.cm;version=1.4 >> >> It does not only import but also export. So you should fine. > > Yes if our consumer bundles import cm with [1.3,2) but no if we actually want > to wire them to an 1.3 exporter. > >>>> and thus can't be used with cpmn 4.2.0 without tweaking. >> >> Using the cmpn as a bundle is problematic since you then have to make sure >> all implementations of the specs actually adhere to those versions ... > > Which can be done if compendium bundles actually import a broad(er) range > that includes older versions than the one they embed/export. Unless I'm > overlooking something? Hmm, interesting thought. Given that 1.4 is backwards compatible and the configadmin bundle itself does not really leverage 1.4 API, the configadmin bundle could in fact export 1.4 but re-import 1.3 .... still, once the configadmin bundle is resolved further bundles resolving would resolve to configadmin's 1.4 export (since the have to wire to the highest resolved exported version) and thus would never be able to talk to the configadmin bundle.... >>> but if it's compatible, maybe we should not branch at all?! >> >> The problem is, that we cannot currently release (for policy reasons) until >> the OSGi Alliance officially releases the new API. > > Can we release with the current API instead of the new one? Not sure. I think it would be better to create a configadmin-1.2 branch and release 1.2.10 from there and change trunk to 1.3.1-SNAPSHOT from where I will then create the 1.4.0 release for configadmin 1.4 Regards Felix
