felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Pouwelse <b...@pouwelse.com>
Subject Re: Proposal for slight amendment to Felix provisional OSGi API policy
Date Fri, 23 Dec 2016 11:02:39 GMT
> 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.bosschaert@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message