I Like the simple version ( org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional="felix" ), and then I think it makes sense to advise a bit more conservative import range like Import-Package: org.osgi.someapi;version="[0.1,0.2)";provisional=felix
And that also implies that the version needs to be updated when a newer version is included in a next version. On Fri, Dec 23, 2016 at 1:41 PM Neil Bartlett <njbartl...@gmail.com> wrote: > 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 > > >
