felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Proposal for slight amendment to Felix provisional OSGi API policy
Date Fri, 23 Dec 2016 19:19:34 GMT
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
>


Mime
View raw message