I fully support this proposal. The major change on release of the API should make sure that we do not get problems when there are changes. As the package name stays the same it will still be easy for users to migrate.
I also hope the OSGi alliance makes the newest API snapshot available in maven as e.g. 0.0.1-SNAPSHOT. So we have a ice way of writing integration tests that alarm us of API changes while the spec is still in flow. Christian 2016-12-23 11:29 GMT+01:00 David Bosschaert <david.bosscha...@gmail.com>: > 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 > -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
