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.
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.
-> richard
On 12/23/16 05:29 , David Bosschaert wrote:
Hi all,
The Felix project has a policy to prevent any releases that contain
provisional, unreleased OSGi APIs [1].
Developing OSGi APIs generally takes a substantial amount of time. In OSGi
RFPs and RFCs are written. Reference Implementations are developed, often
in Open Source such as here at Felix. Conformance Testsuites are written
and the actual spec is written. Then the whole package is voted on a number
of times by the OSGi membership before the spec is published.
Especially when creating a new spec having the implementation used as
widely as possible is very useful for gathering feedback. OTOH the policy
at [1] stands a bit in the way of wider adoption. It requires everyone to
build their own bundles before they can use it or they have to depend on
published snapshots which can really be unstable. If people want to release
an early implementation the policy at [1] requires the OSGi packages to be
renamed, which essentially makes them unusable by early adopters since they
have to change all their imports in their Java source files to pick up the
renamed package name.
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. We should also add the
@Deprecated annotations and the mandatory 'provisional' attribute, but I
think in this case, where the exported API has a version of < 1.0 it could
be ok to not require the package rename.
This will allow users to use the API in their code based on stable Felix
artifacts, and as the API package does not change once at 1.0 they will not
have to change their source code to migrate from the
org.apache.felix.someapi to org.osgi.someapi. They will need to make
changes to the metadata for the import to work with the released 1.0
version but this is usually somewhere central in a build file...
Disclosure: I would like to release the Felix Converter [2] like this and
have already added the @Deprecate and 'provisional' mandatory attribute...
Thoughts anyone?
Best regards,
David
[1]
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
[2] https://svn.apache.org/repos/asf/felix/trunk/converter/converter
