On Mar 22, 2012, at 14:30 PM, Felix Meschberger wrote: > Hi, > > Am 21.03.2012 um 21:01 schrieb Marcel Offermans: > >> On Mar 21, 2012, at 17:07 PM, Bram de Kruijff wrote: >> >>> On Wed, Mar 21, 2012 at 2:55 PM, Felix Meschberger <[email protected]> >>> wrote: >>>> Hi, >>>> >>>> Am 20.03.2012 um 21:47 schrieb Marcel Offermans: >>>> >>>>> Within a different open source project (Amdatu), we recently ran into >>>>> some race conditions in Configuration Admin 1.2.8 that since have been >>>>> fixed in trunk (see FELIX-2813). However, the next scheduled release will >>>>> be one that requires a still unreleased and new version of the OSGi >>>>> specification, which makes it more difficult for people to use right now >>>>> and in the immediate future (I guess a lot of us will want to stay R4.x >>>>> compatible for some time). >>>> >>>> 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? >> The tricky part is that we have not actually seen the spec yet, but judging >> from the version number it got it should indeed be backward compatible. So >> maybe we could just change the import version range. > > Draft is at http://www.osgi.org/download/osgi.residential-4.3.0-pfd.pdf and > it didn't change (IIRC) since then). The API is (for now) copied to our > source tree. > >> >>>> But yes, as long as the spec has not been published I cannot start cutting >>>> a release (and the next update is just around the corner ;-) ) >>>> >>>>> >>>>> Therefore, my question is, would there be more interest in backporting >>>>> such patches to an 1.2.x branch, and doing a new release? >>>>> >>>>> Right now, we applied such patches and made a release within Amdatu for >>>>> ourselves [1], but we would like to donate these patches back to Felix >>>>> and make an official release here (if enough people care). WDYT? >>>> >>>> I would be ok with that. >>>> >>>> What release version are you thinking of ? >>> >>> Sofar, we only backported FELIX-2813 which is a simple bugfix so I >>> think 1.2.9 would be appropriate. Further cherry picking might warrant >>> a 1.3.0. Haven't done a full analysis yet, but would be happy to have >>> a closer look at the changelog. >> >> Until now, I agree with Bram about looking at 1.2.9 > > Well 1.2.10 then, probably. Ah, yes. >> 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? Greetings, Marcel
