On 1/3/17 11:59 , David Bosschaert wrote:
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.
That's irrelevant. The issue at hand is the the org.osgi package namespace.
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...
I'm not sure why you are fixated on the version, since that seems
immaterial to me. The OSGi Alliance has never made any statement about
Felix release policy, but they did have general words in place saying
what the requirements were for being allowed to use their IP.
I'm fairly certain that the OSGi Alliance is not interested in losing
their tight control over the org.osgi package namespace (nor should they
be). Further, some statement saying "yeah, it's ok" doesn't really cut
it if there still exists wording on requirements on who/how we can use
their IP, since they could change their mind and then what? It would
need to be explicit change of terms.
It's been a while, so who knows, maybe the terms have been loosened up
at this point and it would be possible to do it differently, but it
wasn't possible previously without entering a gray area with IP which is
one of the main things that the Apache release process tries to
eliminate confusion over.
-> richard
Cheers,
David
