> On 23 Dec 2016, at 13:36, David Bosschaert <[email protected]> wrote: > > Hi all, > > On 23 December 2016 at 12:13, Jan Willem Janssen < > [email protected]> wrote: > >> >>> On 23 Dec 2016, at 12:30, David Bosschaert <[email protected]> >> wrote: >>> >>> Hi Bram, >>> >>> On 23 December 2016 at 11:02, Bram Pouwelse <[email protected]> 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.
Good compromise. > Needless to say that these mandatory attributes will be removed once the > OSGi API is released and at 1.0 You should want to do that anyways given that the API is no longer considered provisional ;) -- Met vriendelijke groeten | Kind regards Jan Willem Janssen | Software Architect +31 631 765 814 My world is something with Amdatu and Apache Luminis Technologies Churchillplein 1 7314 BZ Apeldoorn +31 88 586 46 00 https://www.luminis.eu KvK (CoC) 09 16 28 93 BTW (VAT) NL8170.94.441.B.01
signature.asc
Description: Message signed with OpenPGP using GPGMail
