This suggestion from David sounds like a reasonable compromise to me. I would point out that if you are building with bnd and you put a bundle with a mandatory attribute on your build path, then bnd will assume that you want to set that attribute on your import. Thus it will work fairly transparently. And of course if you DON’T want provisional APIs, don’t put provisional bundles on your build path. As the developer this is something that you will have full control over.
Neil > On 23 Dec 2016, at 12:36, David Bosschaert <david.bosscha...@gmail.com> wrote: > > Hi all, > > On 23 December 2016 at 12:13, Jan Willem Janssen < > janwillem.jans...@luminis.eu <mailto:janwillem.jans...@luminis.eu>> wrote: > >> >>> On 23 Dec 2016, at 12:30, David Bosschaert <david.bosscha...@gmail.com> >> wrote: >>> >>> Hi Bram, >>> >>> On 23 December 2016 at 11:02, Bram Pouwelse <b...@pouwelse.com> wrote: >>> >>>>> I think it would be nice if we could relax the policy at [1] a little >> bit >>>> and say that it is ok to release bundles with provisional API in >> versions < >>>> 1.0. The OSGi APIs always start their versions at 1.0 so an API version >> 0.2 >>>> will never conflict with an OSGi released API. >>>> >>>> That sounds nice but you can't have major changes in the provisional API >>>> (or you'd loose semantic versioning). >>>> >>>> >>> There is a somewhat unwritten convention that API < 1.0 is 'experimental' >>> and therefore that exported API in versions [0.0, 1.0) does not follow >>> semantic versioning... Basically what you're signing up to by using this >>> 'provisional' API which has a version < 1.0 is that anything could >> change… >> >> Why not go for the empty version of 0.0.0 for such APIs then? I understand >> that there’s a need to express the fact that an API is still actively being >> developed and not yet final, but using versions in the range of [0,1) would >> make stuff just more complex given that they loose all semantics and are >> only “informational” for humans to parse and comprehend. >> >> > Whether we stick with 0.0.0 or allow different versions between [0.0.0, > 1.0) this would still suffer from Bram's point that if multiple projects do > releases that contain provisional API you don't know which one you'll get > from the resolver. > > This could be fixed by using mandatory attributes on the exported package. > It is a somewhat rarely used feature of OSGi. Currently the document at [1] > says to use the following decoration on the exported package: > Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status"; > status="provisional" > > This means that importers can only import this package if they expressly > add this to the import: > Import-Package: ,org.osgi.someapi;version="[0.0,1)";status="provisional" > > We could specialize this a little bit to indicate what project the version > is from > org.osgi.someapi; version="0.1"; mandatory:="status,implemetation"; > status="provisional"; implementation="felix" > or maybe simply: > org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional > ="felix" > > Then the import would become: > Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix > which means that the import will only resolve to the 'felix' variant of the > provisional API. So from a resolution point of view the ambiguity is gone > then. > > Needless to say that these mandatory attributes will be removed once the > OSGi API is released and at 1.0 > > Cheers, > > David > > [1] > http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html > > <http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html>
