Hi Felix and Richard, On 3 January 2017 at 16:40, Richard S. Hall <he...@ungoverned.org> wrote:
> > On 1/3/17 11:21 , Felix Meschberger wrote: > >> Hi >> >> Upfront I like the amended proposal of using a version < 1 and a >> mandatory attribute „provisional“ with value „felix“. As Neil said, BND >> will solve this for imports be it the bndtools or the maven bundle plugin. >> >> Not declaring a version and thus using 0.0.0 will have BND generate a >> version-less import, which essentially means „any version“, which really is >> bad. All exports always should have an export version. >> >> Now, to Richard’s point: I think this is very valid and we better take >> good care here. If we include OSGi API in our releases it is a re-release >> of AL2 licensed bits. Key is re-release. If we release provisional OSGi API >> in the OSGi name space which has not been released by OSGi yet, we are >> essentially first-party releasing it. >> >> So before we go this route, I would like to have the OSGi Alliance make a >> statement on this topic. In fact, it would make sense for the alliance to >> make an official statement not only to the benefit of the Felix project but >> to the benefit of all OSGi-related projects at Apache and elsewhere. >> >> WDYT ? >> > > Yes, this is exactly the point that made us arrive at our policy in the > first place. We do not have permission or release provision API from the > OSGi Alliance. If I recall correctly, we are only granted permissions to > provide _compliant_ implementations of released API. > > We have no way to achieve that requirement, which puts us in a gray area. > Thus, we arrived at 1) only doing snapshots or 2) changing the package name. > > As Felix M. suggests, one way to remedy this is to get additional explicit > permission from the OSGI Alliance that we are allowed to create official > releases containing provisional API. However, this means we could get into > situations where the OSGi Alliance kills something (e.g., Gogo) that we > want to continue and we have created legacy in the OSGi package namespace. > > It sucks, but that is the reality of the situation. > > -> richard > > The OSGi Alliance has never released API with version <1 and I think it never will. This means that any API with version <1 that would be in Felix provisional release would never clash with a released OSGi API. AFAIK OSGi has never made a statement about the Felix release policy but I guess it might be possible to try and get a statement from OSGi that it will never release versions <1 and that implementation projects are allowed to use versions 0.x during the initial creation of an implementation of a new, previously unreleased spec. I can take this up to the OSGi folks and see if I can get a statement like that... Cheers, David
