> 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). Also not sure how big the imports issue is, if the api is fully compatible that would be a find /replace? Regards, Bram On Fri, Dec 23, 2016 at 11:30 AM David Bosschaert < david.bosscha...@gmail.com> 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