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
Regards
Felix
Am 03.01.2017 um 10:46 schrieb David Bosschaert <david.bosscha...@gmail.com>:
Hi Richard,
On 23 December 2016 at 19:19, Richard S. Hall <he...@ungoverned.org> wrote:
I'm not for changing the policy. The whole point behind the policy is that
anything that we released is in some way blessed and lives forever. If we
release packages in the OSGi namespace, they look official even potentially
after the OSGi Alliance dumps an RFC (ala Gogo). There is no way for us to
retract a release.
There will be org.osgi.something API but it will be with a version < 1,
like 0.1 or something like that. Additionally it will have the mandatory
attribute on it as discussed above something like provisional="felix". The
fact that the version is less than one means that it will never clash with
OSGi released API. These two factors mean that nobody will accidentally use
this API. The users will have to put the mandatory attribute on the import
in order to use it.
So, yes, it makes the process a little bit of a pain, but that was sort of
the point, so we could make the status clear. Besides, using a temporary
package name until a spec if final and then doing a global search/replace
when it goes final isn't really that painful.
I think that experience over the years tells us that the temporary package
name basically means that nobody uses it. I think that others on this
thread have echoed that the temporary package name doesn't work for them.
As you say the process is a bit of a pain and my point is that this stands
in the way of adoption and feedback of new APIs. With this modification to
the policy adoption and feedback becomes easier and less painful while we
still retain the barriers that require people to consciously decide to use
the provisional API...
Cheers,
David
