+1 I'd really like this support as well. As an RI writer the prospect of having to use a different package name during the API development process is not appealing at all.
- Ray On Fri, Dec 23, 2016 at 8:01 AM, Bram Pouwelse <b...@pouwelse.com> wrote: > 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 > > > > > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
