You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Bosschaert <da...@gmail.com> on 2016/12/23 10:29:41 UTC

Proposal for slight amendment to Felix provisional OSGi API policy

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

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Felix Meschberger <fm...@adobe.com>.
Hi

As of now, we don’t have an official branch policy. In fact we had a discussion before and we decided against such.

So I would think that we should continue releasing from trunk and from trunk only.

As such I like Tom’s proposal for a R-Next working branch. And since OSGi generally releases yearly with just consecutive spec version numbers we could just create a single branches/osgi-r-7 (or 8 or 9 or …) branch where we have branch copies of the specs we implement.

This is orthogonal, though, to the question of whether we should be „releasing“ provisional API in the org.osgi namespace.

Regards
Felix

> Am 04.01.2017 um 15:23 schrieb Thomas Watson <tj...@gmail.com>:
> 
> My preference would be to do new osgi R-Next work in a dedicated feature
> branch instead of directly in trunk.  That way trunk remains releasable at
> all times.  But if we want to instead branch each project when its trunk
> version becomes unreleasable then I guess that is fine, but it does seem
> confusing.
> 
> If that is what felix dev has agreed to then I do request a branch for scr
> to release some fixes for the R6 scr implementation.  I'm have a few fixes
> that I need to get released very soon in order to allow the felix scr
> implementation to be used as the DS implementation in Eclipse.
> 
> Tom
> 
> On Wed, Jan 4, 2017 at 1:56 AM, Carsten Ziegeler <cz...@apache.org>
> wrote:
> 
>> Thomas Watson wrote
>>> This has come to my attention because I am working on some fixes in the
>> SCR
>>> implementation.  I noticed the latest SCR in trunk now depends on
>>> org.apache.felix.configadmin 1.9.0-SNAPSHOT.  And I think
>>> org.apache.felix.configadmin 1.9.0 is being used to implement OSGi R7.
>> So
>>> now we have OSGi R7 API updates in trunk for existing OSGi packages.  If
>> I
>>> understand correctly that means trunk is no longer in a state where we
>> can
>>> release SCR or configadmin out of.  Instead we have to create a branch to
>>> get new releases of these bundles until a time when OSGi R7 is finalized
>>> and released.  That seems like a bad state to be in.
>>> 
>> 
>> We already have the branch for config admin and if we think that we need
>> another R6 based release of SCR we can create the branch on demand like
>> we did with config admin.
>> I started with these two projects in a branch and at one point we have
>> to merge the branch into trunk. I thought that now is the time as I
>> didn't expect another release before R7 will be out. Might be wrong...
>> In any case, creating that branch is easy. Just shout and it will be done.
>> 
>> Carsten
>> 
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Thomas Watson <tj...@gmail.com>.
My preference would be to do new osgi R-Next work in a dedicated feature
branch instead of directly in trunk.  That way trunk remains releasable at
all times.  But if we want to instead branch each project when its trunk
version becomes unreleasable then I guess that is fine, but it does seem
confusing.

If that is what felix dev has agreed to then I do request a branch for scr
to release some fixes for the R6 scr implementation.  I'm have a few fixes
that I need to get released very soon in order to allow the felix scr
implementation to be used as the DS implementation in Eclipse.

Tom

On Wed, Jan 4, 2017 at 1:56 AM, Carsten Ziegeler <cz...@apache.org>
wrote:

> Thomas Watson wrote
> > This has come to my attention because I am working on some fixes in the
> SCR
> > implementation.  I noticed the latest SCR in trunk now depends on
> > org.apache.felix.configadmin 1.9.0-SNAPSHOT.  And I think
> > org.apache.felix.configadmin 1.9.0 is being used to implement OSGi R7.
> So
> > now we have OSGi R7 API updates in trunk for existing OSGi packages.  If
> I
> > understand correctly that means trunk is no longer in a state where we
> can
> > release SCR or configadmin out of.  Instead we have to create a branch to
> > get new releases of these bundles until a time when OSGi R7 is finalized
> > and released.  That seems like a bad state to be in.
> >
>
> We already have the branch for config admin and if we think that we need
> another R6 based release of SCR we can create the branch on demand like
> we did with config admin.
> I started with these two projects in a branch and at one point we have
> to merge the branch into trunk. I thought that now is the time as I
> didn't expect another release before R7 will be out. Might be wrong...
> In any case, creating that branch is easy. Just shout and it will be done.
>
>  Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Carsten Ziegeler <cz...@apache.org>.
Thomas Watson wrote
> This has come to my attention because I am working on some fixes in the SCR
> implementation.  I noticed the latest SCR in trunk now depends on
> org.apache.felix.configadmin 1.9.0-SNAPSHOT.  And I think
> org.apache.felix.configadmin 1.9.0 is being used to implement OSGi R7.  So
> now we have OSGi R7 API updates in trunk for existing OSGi packages.  If I
> understand correctly that means trunk is no longer in a state where we can
> release SCR or configadmin out of.  Instead we have to create a branch to
> get new releases of these bundles until a time when OSGi R7 is finalized
> and released.  That seems like a bad state to be in.
> 

We already have the branch for config admin and if we think that we need
another R6 based release of SCR we can create the branch on demand like
we did with config admin.
I started with these two projects in a branch and at one point we have
to merge the branch into trunk. I thought that now is the time as I
didn't expect another release before R7 will be out. Might be wrong...
In any case, creating that branch is easy. Just shout and it will be done.

 Carsten

-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Thomas Watson <tj...@gmail.com>.
This has come to my attention because I am working on some fixes in the SCR
implementation.  I noticed the latest SCR in trunk now depends on
org.apache.felix.configadmin 1.9.0-SNAPSHOT.  And I think
org.apache.felix.configadmin 1.9.0 is being used to implement OSGi R7.  So
now we have OSGi R7 API updates in trunk for existing OSGi packages.  If I
understand correctly that means trunk is no longer in a state where we can
release SCR or configadmin out of.  Instead we have to create a branch to
get new releases of these bundles until a time when OSGi R7 is finalized
and released.  That seems like a bad state to be in.

Tom

On Tue, Jan 3, 2017 at 1:25 PM, David Bosschaert <david.bosschaert@gmail.com
> wrote:

> Hi Tom,
>
> My proposal here only applies to implementations of entirely new specs.
> Updates on existing specs are not covered, hence the point around versions
> <1.
>
> I completely agree that updates to existing specs should be done on a
> branch to keep trunk releasable.
>
> Cheers,
>
> David
>
> On 3 January 2017 at 19:22, Thomas Watson <tj...@gmail.com> wrote:
>
> > Why do OSGi R-next work directly in trunk where I would expect releases
> > could be done at any time.  It seems to me that trunk should remain
> > 'releasable'.  It would be much more simple to do OSGi R-next work in a
> > dedicated branch where you have the freedom to put interim OSGi APIs
> > assuming we would never produce a release from the osgi-r-next branch.
> > Instead, stuff from the osgi-r-next branch would be selectively merged
> into
> > trunk when they are ready AND the OSGi specification has gone final.
> >
> > Also, I don't get this <1 version proposal.  That may seem fine for new
> API
> > packages, but what about changes to existing OSGi API packages that are
> > happening in R7?  Surely these cannot go to <1.  Perhaps I missed what
> > happens here from the original proposal.
> >
> > Tom
> >
> > On Tue, Jan 3, 2017 at 11:21 AM, Richard S. Hall <he...@ungoverned.org>
> > wrote:
> >
> > >
> > > On 1/3/17 11:59 , David Bosschaert wrote:
> > >
> > >> Hi Felix and Richard,
> > >>
> > >> On 3 January 2017 at 16:40, Richard S. Hall <he...@ungoverned.org>
> > wrote:
> > >>
> > >> On 1/3/17 11:21 , Felix Meschberger wrote:
> > >>>
> > >>> Hi
> > >>>>
> > >>>> Upfront I like the amended proposal of using a version < 1 and a
> > >>>> mandatory attribute „provisional“ with value „felix“. As Neil said,
> > BND
> > >>>> will solve this for imports be it the bndtools or the maven bundle
> > >>>> plugin.
> > >>>>
> > >>>> Not declaring a version and thus using 0.0.0 will have BND generate
> a
> > >>>> version-less import, which essentially means „any version“, which
> > >>>> really is
> > >>>> bad. All exports always should have an export version.
> > >>>>
> > >>>> Now, to Richard’s point: I think this is very valid and we better
> take
> > >>>> good care here. If we include OSGi API in our releases it is a
> > >>>> re-release
> > >>>> of AL2 licensed bits. Key is re-release. If we release provisional
> > OSGi
> > >>>> API
> > >>>> in the OSGi name space which has not been released by OSGi yet, we
> are
> > >>>> essentially first-party releasing it.
> > >>>>
> > >>>> So before we go this route, I would like to have the OSGi Alliance
> > make
> > >>>> a
> > >>>> statement on this topic. In fact, it would make sense for the
> alliance
> > >>>> to
> > >>>> make an official statement not only to the benefit of the Felix
> > project
> > >>>> but
> > >>>> to the benefit of all OSGi-related projects at Apache and elsewhere.
> > >>>>
> > >>>> WDYT ?
> > >>>>
> > >>>> Yes, this is exactly the point that made us arrive at our policy in
> > the
> > >>> first place. We do not have permission or release provision API from
> > the
> > >>> OSGi Alliance. If I recall correctly, we are only granted permissions
> > to
> > >>> provide _compliant_ implementations of released API.
> > >>>
> > >>> We have no way to achieve that requirement, which puts us in a gray
> > area.
> > >>> Thus, we arrived at 1) only doing snapshots or 2) changing the
> package
> > >>> name.
> > >>>
> > >>> As Felix M. suggests, one way to remedy this is to get additional
> > >>> explicit
> > >>> permission from the OSGI Alliance that we are allowed to create
> > official
> > >>> releases containing provisional API. However, this means we could get
> > >>> into
> > >>> situations where the OSGi Alliance kills something (e.g., Gogo) that
> we
> > >>> want to continue and we have created legacy in the OSGi package
> > >>> namespace.
> > >>>
> > >>> It sucks, but that is the reality of the situation.
> > >>>
> > >>> -> richard
> > >>>
> > >>>
> > >>> The OSGi Alliance has never released API with version <1 and I think
> it
> > >> never will. This means that any API with version <1 that would be in
> > Felix
> > >> provisional release would never clash with a released OSGi API.
> > >>
> > >
> > > That's irrelevant. The issue at hand is the the org.osgi package
> > namespace.
> > >
> > > AFAIK OSGi has never made a statement about the Felix release policy
> but
> > I
> > >> guess it might be possible to try and get a statement from OSGi that
> it
> > >> will never release versions <1 and that implementation projects are
> > >> allowed
> > >> to use versions 0.x during the initial creation of an implementation
> of
> > a
> > >> new, previously unreleased spec.
> > >>
> > >> I can take this up to the OSGi folks and see if I can get a statement
> > like
> > >> that...
> > >>
> > >
> > > I'm not sure why you are fixated on the version, since that seems
> > > immaterial to me. The OSGi Alliance has never made any statement about
> > > Felix release policy, but they did have general words in place saying
> > what
> > > the requirements were for being allowed to use their IP.
> > >
> > > I'm fairly certain that the OSGi Alliance is not interested in losing
> > > their tight control over the org.osgi package namespace (nor should
> they
> > > be). Further, some statement saying "yeah, it's ok" doesn't really cut
> it
> > > if there still exists wording on requirements on who/how we can use
> their
> > > IP, since they could change their mind and then what? It would need to
> be
> > > explicit change of terms.
> > >
> > > It's been a while, so who knows, maybe the terms have been loosened up
> at
> > > this point and it would be possible to do it differently, but it wasn't
> > > possible previously without entering a gray area with IP which is one
> of
> > > the main things that the Apache release process tries to eliminate
> > > confusion over.
> > >
> > > -> richard
> > >
> > >
> > >> Cheers,
> > >>
> > >> David
> > >>
> > >>
> > >
> >
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by David Bosschaert <da...@gmail.com>.
Hi Tom,

My proposal here only applies to implementations of entirely new specs.
Updates on existing specs are not covered, hence the point around versions
<1.

I completely agree that updates to existing specs should be done on a
branch to keep trunk releasable.

Cheers,

David

On 3 January 2017 at 19:22, Thomas Watson <tj...@gmail.com> wrote:

> Why do OSGi R-next work directly in trunk where I would expect releases
> could be done at any time.  It seems to me that trunk should remain
> 'releasable'.  It would be much more simple to do OSGi R-next work in a
> dedicated branch where you have the freedom to put interim OSGi APIs
> assuming we would never produce a release from the osgi-r-next branch.
> Instead, stuff from the osgi-r-next branch would be selectively merged into
> trunk when they are ready AND the OSGi specification has gone final.
>
> Also, I don't get this <1 version proposal.  That may seem fine for new API
> packages, but what about changes to existing OSGi API packages that are
> happening in R7?  Surely these cannot go to <1.  Perhaps I missed what
> happens here from the original proposal.
>
> Tom
>
> On Tue, Jan 3, 2017 at 11:21 AM, Richard S. Hall <he...@ungoverned.org>
> wrote:
>
> >
> > On 1/3/17 11:59 , David Bosschaert wrote:
> >
> >> Hi Felix and Richard,
> >>
> >> On 3 January 2017 at 16:40, Richard S. Hall <he...@ungoverned.org>
> wrote:
> >>
> >> On 1/3/17 11:21 , Felix Meschberger wrote:
> >>>
> >>> Hi
> >>>>
> >>>> Upfront I like the amended proposal of using a version < 1 and a
> >>>> mandatory attribute „provisional“ with value „felix“. As Neil said,
> BND
> >>>> will solve this for imports be it the bndtools or the maven bundle
> >>>> plugin.
> >>>>
> >>>> Not declaring a version and thus using 0.0.0 will have BND generate a
> >>>> version-less import, which essentially means „any version“, which
> >>>> really is
> >>>> bad. All exports always should have an export version.
> >>>>
> >>>> Now, to Richard’s point: I think this is very valid and we better take
> >>>> good care here. If we include OSGi API in our releases it is a
> >>>> re-release
> >>>> of AL2 licensed bits. Key is re-release. If we release provisional
> OSGi
> >>>> API
> >>>> in the OSGi name space which has not been released by OSGi yet, we are
> >>>> essentially first-party releasing it.
> >>>>
> >>>> So before we go this route, I would like to have the OSGi Alliance
> make
> >>>> a
> >>>> statement on this topic. In fact, it would make sense for the alliance
> >>>> to
> >>>> make an official statement not only to the benefit of the Felix
> project
> >>>> but
> >>>> to the benefit of all OSGi-related projects at Apache and elsewhere.
> >>>>
> >>>> WDYT ?
> >>>>
> >>>> Yes, this is exactly the point that made us arrive at our policy in
> the
> >>> first place. We do not have permission or release provision API from
> the
> >>> OSGi Alliance. If I recall correctly, we are only granted permissions
> to
> >>> provide _compliant_ implementations of released API.
> >>>
> >>> We have no way to achieve that requirement, which puts us in a gray
> area.
> >>> Thus, we arrived at 1) only doing snapshots or 2) changing the package
> >>> name.
> >>>
> >>> As Felix M. suggests, one way to remedy this is to get additional
> >>> explicit
> >>> permission from the OSGI Alliance that we are allowed to create
> official
> >>> releases containing provisional API. However, this means we could get
> >>> into
> >>> situations where the OSGi Alliance kills something (e.g., Gogo) that we
> >>> want to continue and we have created legacy in the OSGi package
> >>> namespace.
> >>>
> >>> It sucks, but that is the reality of the situation.
> >>>
> >>> -> richard
> >>>
> >>>
> >>> The OSGi Alliance has never released API with version <1 and I think it
> >> never will. This means that any API with version <1 that would be in
> Felix
> >> provisional release would never clash with a released OSGi API.
> >>
> >
> > That's irrelevant. The issue at hand is the the org.osgi package
> namespace.
> >
> > AFAIK OSGi has never made a statement about the Felix release policy but
> I
> >> guess it might be possible to try and get a statement from OSGi that it
> >> will never release versions <1 and that implementation projects are
> >> allowed
> >> to use versions 0.x during the initial creation of an implementation of
> a
> >> new, previously unreleased spec.
> >>
> >> I can take this up to the OSGi folks and see if I can get a statement
> like
> >> that...
> >>
> >
> > I'm not sure why you are fixated on the version, since that seems
> > immaterial to me. The OSGi Alliance has never made any statement about
> > Felix release policy, but they did have general words in place saying
> what
> > the requirements were for being allowed to use their IP.
> >
> > I'm fairly certain that the OSGi Alliance is not interested in losing
> > their tight control over the org.osgi package namespace (nor should they
> > be). Further, some statement saying "yeah, it's ok" doesn't really cut it
> > if there still exists wording on requirements on who/how we can use their
> > IP, since they could change their mind and then what? It would need to be
> > explicit change of terms.
> >
> > It's been a while, so who knows, maybe the terms have been loosened up at
> > this point and it would be possible to do it differently, but it wasn't
> > possible previously without entering a gray area with IP which is one of
> > the main things that the Apache release process tries to eliminate
> > confusion over.
> >
> > -> richard
> >
> >
> >> Cheers,
> >>
> >> David
> >>
> >>
> >
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Thomas Watson <tj...@gmail.com>.
Why do OSGi R-next work directly in trunk where I would expect releases
could be done at any time.  It seems to me that trunk should remain
'releasable'.  It would be much more simple to do OSGi R-next work in a
dedicated branch where you have the freedom to put interim OSGi APIs
assuming we would never produce a release from the osgi-r-next branch.
Instead, stuff from the osgi-r-next branch would be selectively merged into
trunk when they are ready AND the OSGi specification has gone final.

Also, I don't get this <1 version proposal.  That may seem fine for new API
packages, but what about changes to existing OSGi API packages that are
happening in R7?  Surely these cannot go to <1.  Perhaps I missed what
happens here from the original proposal.

Tom

On Tue, Jan 3, 2017 at 11:21 AM, Richard S. Hall <he...@ungoverned.org>
wrote:

>
> On 1/3/17 11:59 , David Bosschaert wrote:
>
>> Hi Felix and Richard,
>>
>> On 3 January 2017 at 16:40, Richard S. Hall <he...@ungoverned.org> wrote:
>>
>> On 1/3/17 11:21 , Felix Meschberger wrote:
>>>
>>> Hi
>>>>
>>>> Upfront I like the amended proposal of using a version < 1 and a
>>>> mandatory attribute „provisional“ with value „felix“. As Neil said, BND
>>>> will solve this for imports be it the bndtools or the maven bundle
>>>> plugin.
>>>>
>>>> Not declaring a version and thus using 0.0.0 will have BND generate a
>>>> version-less import, which essentially means „any version“, which
>>>> really is
>>>> bad. All exports always should have an export version.
>>>>
>>>> Now, to Richard’s point: I think this is very valid and we better take
>>>> good care here. If we include OSGi API in our releases it is a
>>>> re-release
>>>> of AL2 licensed bits. Key is re-release. If we release provisional OSGi
>>>> API
>>>> in the OSGi name space which has not been released by OSGi yet, we are
>>>> essentially first-party releasing it.
>>>>
>>>> So before we go this route, I would like to have the OSGi Alliance make
>>>> a
>>>> statement on this topic. In fact, it would make sense for the alliance
>>>> to
>>>> make an official statement not only to the benefit of the Felix project
>>>> but
>>>> to the benefit of all OSGi-related projects at Apache and elsewhere.
>>>>
>>>> WDYT ?
>>>>
>>>> Yes, this is exactly the point that made us arrive at our policy in the
>>> first place. We do not have permission or release provision API from the
>>> OSGi Alliance. If I recall correctly, we are only granted permissions to
>>> provide _compliant_ implementations of released API.
>>>
>>> We have no way to achieve that requirement, which puts us in a gray area.
>>> Thus, we arrived at 1) only doing snapshots or 2) changing the package
>>> name.
>>>
>>> As Felix M. suggests, one way to remedy this is to get additional
>>> explicit
>>> permission from the OSGI Alliance that we are allowed to create official
>>> releases containing provisional API. However, this means we could get
>>> into
>>> situations where the OSGi Alliance kills something (e.g., Gogo) that we
>>> want to continue and we have created legacy in the OSGi package
>>> namespace.
>>>
>>> It sucks, but that is the reality of the situation.
>>>
>>> -> richard
>>>
>>>
>>> The OSGi Alliance has never released API with version <1 and I think it
>> never will. This means that any API with version <1 that would be in Felix
>> provisional release would never clash with a released OSGi API.
>>
>
> That's irrelevant. The issue at hand is the the org.osgi package namespace.
>
> AFAIK OSGi has never made a statement about the Felix release policy but I
>> guess it might be possible to try and get a statement from OSGi that it
>> will never release versions <1 and that implementation projects are
>> allowed
>> to use versions 0.x during the initial creation of an implementation of a
>> new, previously unreleased spec.
>>
>> I can take this up to the OSGi folks and see if I can get a statement like
>> that...
>>
>
> I'm not sure why you are fixated on the version, since that seems
> immaterial to me. The OSGi Alliance has never made any statement about
> Felix release policy, but they did have general words in place saying what
> the requirements were for being allowed to use their IP.
>
> I'm fairly certain that the OSGi Alliance is not interested in losing
> their tight control over the org.osgi package namespace (nor should they
> be). Further, some statement saying "yeah, it's ok" doesn't really cut it
> if there still exists wording on requirements on who/how we can use their
> IP, since they could change their mind and then what? It would need to be
> explicit change of terms.
>
> It's been a while, so who knows, maybe the terms have been loosened up at
> this point and it would be possible to do it differently, but it wasn't
> possible previously without entering a gray area with IP which is one of
> the main things that the Apache release process tries to eliminate
> confusion over.
>
> -> richard
>
>
>> Cheers,
>>
>> David
>>
>>
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/3/17 11:59 , David Bosschaert wrote:
> Hi Felix and Richard,
>
> On 3 January 2017 at 16:40, Richard S. Hall <he...@ungoverned.org> wrote:
>
>> On 1/3/17 11:21 , Felix Meschberger wrote:
>>
>>> Hi
>>>
>>> Upfront I like the amended proposal of using a version < 1 and a
>>> mandatory attribute \u201eprovisional\u201c with value \u201efelix\u201c. As Neil said, BND
>>> will solve this for imports be it the bndtools or the maven bundle plugin.
>>>
>>> Not declaring a version and thus using 0.0.0 will have BND generate a
>>> version-less import, which essentially means \u201eany version\u201c, which really is
>>> bad. All exports always should have an export version.
>>>
>>> Now, to Richard\u2019s point: I think this is very valid and we better take
>>> good care here. If we include OSGi API in our releases it is a re-release
>>> of AL2 licensed bits. Key is re-release. If we release provisional OSGi API
>>> in the OSGi name space which has not been released by OSGi yet, we are
>>> essentially first-party releasing it.
>>>
>>> So before we go this route, I would like to have the OSGi Alliance make a
>>> statement on this topic. In fact, it would make sense for the alliance to
>>> make an official statement not only to the benefit of the Felix project but
>>> to the benefit of all OSGi-related projects at Apache and elsewhere.
>>>
>>> WDYT ?
>>>
>> Yes, this is exactly the point that made us arrive at our policy in the
>> first place. We do not have permission or release provision API from the
>> OSGi Alliance. If I recall correctly, we are only granted permissions to
>> provide _compliant_ implementations of released API.
>>
>> We have no way to achieve that requirement, which puts us in a gray area.
>> Thus, we arrived at 1) only doing snapshots or 2) changing the package name.
>>
>> As Felix M. suggests, one way to remedy this is to get additional explicit
>> permission from the OSGI Alliance that we are allowed to create official
>> releases containing provisional API. However, this means we could get into
>> situations where the OSGi Alliance kills something (e.g., Gogo) that we
>> want to continue and we have created legacy in the OSGi package namespace.
>>
>> It sucks, but that is the reality of the situation.
>>
>> -> richard
>>
>>
> The OSGi Alliance has never released API with version <1 and I think it
> never will. This means that any API with version <1 that would be in Felix
> provisional release would never clash with a released OSGi API.

That's irrelevant. The issue at hand is the the org.osgi package namespace.

> AFAIK OSGi has never made a statement about the Felix release policy but I
> guess it might be possible to try and get a statement from OSGi that it
> will never release versions <1 and that implementation projects are allowed
> to use versions 0.x during the initial creation of an implementation of a
> new, previously unreleased spec.
>
> I can take this up to the OSGi folks and see if I can get a statement like
> that...

I'm not sure why you are fixated on the version, since that seems 
immaterial to me. The OSGi Alliance has never made any statement about 
Felix release policy, but they did have general words in place saying 
what the requirements were for being allowed to use their IP.

I'm fairly certain that the OSGi Alliance is not interested in losing 
their tight control over the org.osgi package namespace (nor should they 
be). Further, some statement saying "yeah, it's ok" doesn't really cut 
it if there still exists wording on requirements on who/how we can use 
their IP, since they could change their mind and then what? It would 
need to be explicit change of terms.

It's been a while, so who knows, maybe the terms have been loosened up 
at this point and it would be possible to do it differently, but it 
wasn't possible previously without entering a gray area with IP which is 
one of the main things that the Apache release process tries to 
eliminate confusion over.

-> richard

>
> Cheers,
>
> David
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Christian Schneider <ch...@die-schneider.net>.
I understand that the OSGi alliance would not release an unfinished spec .. but I think it would not need to.

What I propose instead is that the alliance develops specs like we develop open source software. The spec could be defined in a maven project on github.
There would be a daily build of the spec to a maven snapshot repo. When a spec version is finalized there would be a version tag and a release build to maven central.

This would allow several positive things:

1. People could look into the current state of the spec and propose changes in form of pull requests
2. Implementors and users of the spec could do daily builds against the snapshots and this way be notifed of changes quickly. This would speed up the feedback cycle in regard to usability of the spec.
3. As the spec would be published by the alliance no third party would need to first time release the spec
4. When there is need the alliance could also release beta versions of a spec like 0.9.0. So implementors could base a release on a fixed version to produce there own milstone of beta releases.

I know that such a change would be difficult to achieve in the alliance but I think it would be worth the effort.

Christian

> The OSGi Alliance has never released API with version <1 and I think it
> never will. This means that any API with version <1 that would be in Felix
> provisional release would never clash with a released OSGi API.
>
> AFAIK OSGi has never made a statement about the Felix release policy but I
> guess it might be possible to try and get a statement from OSGi that it
> will never release versions <1 and that implementation projects are allowed
> to use versions 0.x during the initial creation of an implementation of a
> new, previously unreleased spec.
>
> I can take this up to the OSGi folks and see if I can get a statement like
> that...
>
> Cheers,
>
> David
>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by David Bosschaert <da...@gmail.com>.
Hi Felix and Richard,

On 3 January 2017 at 16:40, Richard S. Hall <he...@ungoverned.org> wrote:

>
> On 1/3/17 11:21 , Felix Meschberger wrote:
>
>> Hi
>>
>> Upfront I like the amended proposal of using a version < 1 and a
>> mandatory attribute „provisional“ with value „felix“. As Neil said, BND
>> will solve this for imports be it the bndtools or the maven bundle plugin.
>>
>> Not declaring a version and thus using 0.0.0 will have BND generate a
>> version-less import, which essentially means „any version“, which really is
>> bad. All exports always should have an export version.
>>
>> Now, to Richard’s point: I think this is very valid and we better take
>> good care here. If we include OSGi API in our releases it is a re-release
>> of AL2 licensed bits. Key is re-release. If we release provisional OSGi API
>> in the OSGi name space which has not been released by OSGi yet, we are
>> essentially first-party releasing it.
>>
>> So before we go this route, I would like to have the OSGi Alliance make a
>> statement on this topic. In fact, it would make sense for the alliance to
>> make an official statement not only to the benefit of the Felix project but
>> to the benefit of all OSGi-related projects at Apache and elsewhere.
>>
>> WDYT ?
>>
>
> Yes, this is exactly the point that made us arrive at our policy in the
> first place. We do not have permission or release provision API from the
> OSGi Alliance. If I recall correctly, we are only granted permissions to
> provide _compliant_ implementations of released API.
>
> We have no way to achieve that requirement, which puts us in a gray area.
> Thus, we arrived at 1) only doing snapshots or 2) changing the package name.
>
> As Felix M. suggests, one way to remedy this is to get additional explicit
> permission from the OSGI Alliance that we are allowed to create official
> releases containing provisional API. However, this means we could get into
> situations where the OSGi Alliance kills something (e.g., Gogo) that we
> want to continue and we have created legacy in the OSGi package namespace.
>
> It sucks, but that is the reality of the situation.
>
> -> richard
>
>
The OSGi Alliance has never released API with version <1 and I think it
never will. This means that any API with version <1 that would be in Felix
provisional release would never clash with a released OSGi API.

AFAIK OSGi has never made a statement about the Felix release policy but I
guess it might be possible to try and get a statement from OSGi that it
will never release versions <1 and that implementation projects are allowed
to use versions 0.x during the initial creation of an implementation of a
new, previously unreleased spec.

I can take this up to the OSGi folks and see if I can get a statement like
that...

Cheers,

David

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 1/3/17 11:21 , Felix Meschberger wrote:
> Hi
>
> Upfront I like the amended proposal of using a version < 1 and a mandatory attribute \u201eprovisional\u201c with value \u201efelix\u201c. As Neil said, BND will solve this for imports be it the bndtools or the maven bundle plugin.
>
> Not declaring a version and thus using 0.0.0 will have BND generate a version-less import, which essentially means \u201eany version\u201c, which really is bad. All exports always should have an export version.
>
> Now, to Richard\u2019s point: I think this is very valid and we better take good care here. If we include OSGi API in our releases it is a re-release of AL2 licensed bits. Key is re-release. If we release provisional OSGi API in the OSGi name space which has not been released by OSGi yet, we are essentially first-party releasing it.
>
> So before we go this route, I would like to have the OSGi Alliance make a statement on this topic. In fact, it would make sense for the alliance to make an official statement not only to the benefit of the Felix project but to the benefit of all OSGi-related projects at Apache and elsewhere.
>
> WDYT ?

Yes, this is exactly the point that made us arrive at our policy in the 
first place. We do not have permission or release provision API from the 
OSGi Alliance. If I recall correctly, we are only granted permissions to 
provide _compliant_ implementations of released API.

We have no way to achieve that requirement, which puts us in a gray 
area. Thus, we arrived at 1) only doing snapshots or 2) changing the 
package name.

As Felix M. suggests, one way to remedy this is to get additional 
explicit permission from the OSGI Alliance that we are allowed to create 
official releases containing provisional API. However, this means we 
could get into situations where the OSGi Alliance kills something (e.g., 
Gogo) that we want to continue and we have created legacy in the OSGi 
package namespace.

It sucks, but that is the reality of the situation.

-> richard

>
> Regards
> Felix
>
>
>> Am 03.01.2017 um 10:46 schrieb David Bosschaert <da...@gmail.com>:
>>
>> Hi Richard,
>>
>> On 23 December 2016 at 19:19, Richard S. Hall <he...@ungoverned.org> wrote:
>>
>>> 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.
>>>
>> There will be org.osgi.something API but it will be with a version < 1,
>> like 0.1 or something like that. Additionally it will have the mandatory
>> attribute on it as discussed above something like provisional="felix". The
>> fact that the version is less than one means that it will never clash with
>> OSGi released API. These two factors mean that nobody will accidentally use
>> this API. The users will have to put the mandatory attribute on the import
>> in order to use it.
>>
>>
>>> 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.
>>>
>>>
>> I think that experience over the years tells us that the temporary package
>> name basically means that nobody uses it. I think that others on this
>> thread have echoed that the temporary package name doesn't work for them.
>>
>> As you say the process is a bit of a pain and my point is that this stands
>> in the way of adoption and feedback of new APIs. With this modification to
>> the policy adoption and feedback becomes easier and less painful while we
>> still retain the barriers that require people to consciously decide to use
>> the provisional API...
>>
>> Cheers,
>>
>> David

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Felix Meschberger <fm...@adobe.com>.
Hi

Upfront I like the amended proposal of using a version < 1 and a mandatory attribute „provisional“ with value „felix“. As Neil said, BND will solve this for imports be it the bndtools or the maven bundle plugin.

Not declaring a version and thus using 0.0.0 will have BND generate a version-less import, which essentially means „any version“, which really is bad. All exports always should have an export version.

Now, to Richard’s point: I think this is very valid and we better take good care here. If we include OSGi API in our releases it is a re-release of AL2 licensed bits. Key is re-release. If we release provisional OSGi API in the OSGi name space which has not been released by OSGi yet, we are essentially first-party releasing it.

So before we go this route, I would like to have the OSGi Alliance make a statement on this topic. In fact, it would make sense for the alliance to make an official statement not only to the benefit of the Felix project but to the benefit of all OSGi-related projects at Apache and elsewhere.

WDYT ?

Regards
Felix


> Am 03.01.2017 um 10:46 schrieb David Bosschaert <da...@gmail.com>:
> 
> Hi Richard,
> 
> On 23 December 2016 at 19:19, Richard S. Hall <he...@ungoverned.org> wrote:
> 
>> 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.
>> 
> 
> There will be org.osgi.something API but it will be with a version < 1,
> like 0.1 or something like that. Additionally it will have the mandatory
> attribute on it as discussed above something like provisional="felix". The
> fact that the version is less than one means that it will never clash with
> OSGi released API. These two factors mean that nobody will accidentally use
> this API. The users will have to put the mandatory attribute on the import
> in order to use it.
> 
> 
>> 
>> 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.
>> 
>> 
> I think that experience over the years tells us that the temporary package
> name basically means that nobody uses it. I think that others on this
> thread have echoed that the temporary package name doesn't work for them.
> 
> As you say the process is a bit of a pain and my point is that this stands
> in the way of adoption and feedback of new APIs. With this modification to
> the policy adoption and feedback becomes easier and less painful while we
> still retain the barriers that require people to consciously decide to use
> the provisional API...
> 
> Cheers,
> 
> David

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by David Bosschaert <da...@gmail.com>.
Hi Christian,

On 3 January 2017 at 10:00, Christian Schneider <ch...@die-schneider.net>
wrote:

>
>> Why do we need the mandatory provisional attribute? With the version < 1
> we already ensure that we have a clean cut when the
> final API is released.
>
> I think this extra protection only makes it harder to use the API.
>
>
Something like this is already in the current provisional API policy [1]
but it was modified based on discussion earlier in this thread. Basically
it's an extra safeguard to prevent people form accidentally using the
provisional API, for example in case they import the API without specifying
the version number.
It also disambiguates multiple different projects that might use the
non-final API which might be in different stages of development.

Cheers,

David

[1]
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Christian Schneider <ch...@die-schneider.net>.
On 03.01.2017 10:46, David Bosschaert wrote:
> Hi Richard,
>
> On 23 December 2016 at 19:19, Richard S. Hall <he...@ungoverned.org> wrote:
>
>> 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.
>>
> There will be org.osgi.something API but it will be with a version < 1,
> like 0.1 or something like that. Additionally it will have the mandatory
> attribute on it as discussed above something like provisional="felix". The
> fact that the version is less than one means that it will never clash with
> OSGi released API. These two factors mean that nobody will accidentally use
> this API. The users will have to put the mandatory attribute on the import
> in order to use it.
Why do we need the mandatory provisional attribute? With the version < 1 
we already ensure that we have a clean cut when the
final API is released.

I think this extra protection only makes it harder to use the API.

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by David Bosschaert <da...@gmail.com>.
Hi Richard,

On 23 December 2016 at 19:19, Richard S. Hall <he...@ungoverned.org> wrote:

> 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.
>

There will be org.osgi.something API but it will be with a version < 1,
like 0.1 or something like that. Additionally it will have the mandatory
attribute on it as discussed above something like provisional="felix". The
fact that the version is less than one means that it will never clash with
OSGi released API. These two factors mean that nobody will accidentally use
this API. The users will have to put the mandatory attribute on the import
in order to use it.


>
> 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.
>
>
I think that experience over the years tells us that the temporary package
name basically means that nobody uses it. I think that others on this
thread have echoed that the temporary package name doesn't work for them.

As you say the process is a bit of a pain and my point is that this stands
in the way of adoption and feedback of new APIs. With this modification to
the policy adoption and feedback becomes easier and less painful while we
still retain the barriers that require people to consciously decide to use
the provisional API...

Cheers,

David

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1

Good point !

Regards
JB

On 12/23/2016 05:54 PM, Raymond Auge wrote:
> +1
>
> I'd really like this support as well. As an RI writer the prospect of
> having to use a different package name during the API development process
> is not appealing at all.
>
> - Ray
>
> On Fri, Dec 23, 2016 at 8:01 AM, Bram Pouwelse <br...@pouwelse.com> wrote:
>
>> I Like the simple version ( org.osgi.someapi; version="0.1";
>> mandatory:="provisional"; provisional="felix" ), and then I think it makes
>> sense to advise a bit more conservative import range like
>>  Import-Package: org.osgi.someapi;version="[0.1,0.2)";provisional=felix
>>
>> And that also implies that the version needs to be updated when a newer
>> version is included in a next version.
>>
>>
>> On Fri, Dec 23, 2016 at 1:41 PM Neil Bartlett <nj...@gmail.com>
>> wrote:
>>
>>> This suggestion from David sounds like a reasonable compromise to me.
>>>
>>> I would point out that if you are building with bnd and you put a bundle
>>> with a mandatory attribute on your build path, then bnd will assume that
>>> you want to set that attribute on your import. Thus it will work fairly
>>> transparently. And of course if you DON\u2019T want provisional APIs, don\u2019t
>> put
>>> provisional bundles on your build path. As the developer this is
>> something
>>> that you will have full control over.
>>>
>>> Neil
>>>
>>>> On 23 Dec 2016, at 12:36, David Bosschaert <david.bosschaert@gmail.com
>>>
>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> On 23 December 2016 at 12:13, Jan Willem Janssen <
>>>> janwillem.janssen@luminis.eu <ma...@luminis.eu>>
>>> wrote:
>>>>
>>>>>
>>>>>> On 23 Dec 2016, at 12:30, David Bosschaert <
>> david.bosschaert@gmail.com
>>>>
>>>>> wrote:
>>>>>>
>>>>>> Hi Bram,
>>>>>>
>>>>>> On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com>
>> wrote:
>>>>>>
>>>>>>>> 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).
>>>>>>>
>>>>>>>
>>>>>> There is a somewhat unwritten convention that API < 1.0 is
>>> 'experimental'
>>>>>> and therefore that exported API in versions [0.0, 1.0) does not
>> follow
>>>>>> semantic versioning... Basically what you're signing up to by using
>>> this
>>>>>> 'provisional' API which has a version < 1.0 is that anything could
>>>>> change\u2026
>>>>>
>>>>> Why not go for the empty version of 0.0.0 for such APIs then? I
>>> understand
>>>>> that there\u2019s a need to express the fact that an API is still actively
>>> being
>>>>> developed and not yet final, but using versions in the range of [0,1)
>>> would
>>>>> make stuff just more complex given that they loose all semantics and
>> are
>>>>> only \u201cinformational\u201d for humans to parse and comprehend.
>>>>>
>>>>>
>>>> Whether we stick with 0.0.0 or allow different versions between [0.0.0,
>>>> 1.0) this would still suffer from Bram's point that if multiple
>> projects
>>> do
>>>> releases that contain provisional API you don't know which one you'll
>> get
>>>> from the resolver.
>>>>
>>>> This could be fixed by using mandatory attributes on the exported
>>> package.
>>>> It is a somewhat rarely used feature of OSGi. Currently the document at
>>> [1]
>>>> says to use the following decoration on the exported package:
>>>>  Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status";
>>>> status="provisional"
>>>>
>>>> This means that importers can only import this package if they
>> expressly
>>>> add this to the import:
>>>>  Import-Package: ,org.osgi.someapi;version="[0.
>> 0,1)";status="provisional"
>>>>
>>>> We could specialize this a little bit to indicate what project the
>>> version
>>>> is from
>>>>  org.osgi.someapi; version="0.1"; mandatory:="status,implemetation";
>>>> status="provisional"; implementation="felix"
>>>> or maybe simply:
>>>>  org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional
>>>> ="felix"
>>>>
>>>> Then the import would become:
>>>>  Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix
>>>> which means that the import will only resolve to the 'felix' variant of
>>> the
>>>> provisional API. So from a resolution point of view the ambiguity is
>> gone
>>>> then.
>>>>
>>>> Needless to say that these mandatory attributes will be removed once
>> the
>>>> OSGi API is released and at 1.0
>>>>
>>>> Cheers,
>>>>
>>>> David
>>>>
>>>> [1]
>>>>
>>> http://felix.apache.org/documentation/development/
>> provisional-osgi-api-policy.html
>>> <
>>> http://felix.apache.org/documentation/development/
>> provisional-osgi-api-policy.html
>>>>
>>>
>>
>
>
>

-- 
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Raymond Auge <ra...@liferay.com>.
+1

I'd really like this support as well. As an RI writer the prospect of
having to use a different package name during the API development process
is not appealing at all.

- Ray

On Fri, Dec 23, 2016 at 8:01 AM, Bram Pouwelse <br...@pouwelse.com> wrote:

> I Like the simple version ( org.osgi.someapi; version="0.1";
> mandatory:="provisional"; provisional="felix" ), and then I think it makes
> sense to advise a bit more conservative import range like
>  Import-Package: org.osgi.someapi;version="[0.1,0.2)";provisional=felix
>
> And that also implies that the version needs to be updated when a newer
> version is included in a next version.
>
>
> On Fri, Dec 23, 2016 at 1:41 PM Neil Bartlett <nj...@gmail.com>
> wrote:
>
> > This suggestion from David sounds like a reasonable compromise to me.
> >
> > I would point out that if you are building with bnd and you put a bundle
> > with a mandatory attribute on your build path, then bnd will assume that
> > you want to set that attribute on your import. Thus it will work fairly
> > transparently. And of course if you DON’T want provisional APIs, don’t
> put
> > provisional bundles on your build path. As the developer this is
> something
> > that you will have full control over.
> >
> > Neil
> >
> > > On 23 Dec 2016, at 12:36, David Bosschaert <david.bosschaert@gmail.com
> >
> > wrote:
> > >
> > > Hi all,
> > >
> > > On 23 December 2016 at 12:13, Jan Willem Janssen <
> > > janwillem.janssen@luminis.eu <ma...@luminis.eu>>
> > wrote:
> > >
> > >>
> > >>> On 23 Dec 2016, at 12:30, David Bosschaert <
> david.bosschaert@gmail.com
> > >
> > >> wrote:
> > >>>
> > >>> Hi Bram,
> > >>>
> > >>> On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com>
> wrote:
> > >>>
> > >>>>> 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).
> > >>>>
> > >>>>
> > >>> There is a somewhat unwritten convention that API < 1.0 is
> > 'experimental'
> > >>> and therefore that exported API in versions [0.0, 1.0) does not
> follow
> > >>> semantic versioning... Basically what you're signing up to by using
> > this
> > >>> 'provisional' API which has a version < 1.0 is that anything could
> > >> change…
> > >>
> > >> Why not go for the empty version of 0.0.0 for such APIs then? I
> > understand
> > >> that there’s a need to express the fact that an API is still actively
> > being
> > >> developed and not yet final, but using versions in the range of [0,1)
> > would
> > >> make stuff just more complex given that they loose all semantics and
> are
> > >> only “informational” for humans to parse and comprehend.
> > >>
> > >>
> > > Whether we stick with 0.0.0 or allow different versions between [0.0.0,
> > > 1.0) this would still suffer from Bram's point that if multiple
> projects
> > do
> > > releases that contain provisional API you don't know which one you'll
> get
> > > from the resolver.
> > >
> > > This could be fixed by using mandatory attributes on the exported
> > package.
> > > It is a somewhat rarely used feature of OSGi. Currently the document at
> > [1]
> > > says to use the following decoration on the exported package:
> > >  Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status";
> > > status="provisional"
> > >
> > > This means that importers can only import this package if they
> expressly
> > > add this to the import:
> > >  Import-Package: ,org.osgi.someapi;version="[0.
> 0,1)";status="provisional"
> > >
> > > We could specialize this a little bit to indicate what project the
> > version
> > > is from
> > >  org.osgi.someapi; version="0.1"; mandatory:="status,implemetation";
> > > status="provisional"; implementation="felix"
> > > or maybe simply:
> > >  org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional
> > > ="felix"
> > >
> > > Then the import would become:
> > >  Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix
> > > which means that the import will only resolve to the 'felix' variant of
> > the
> > > provisional API. So from a resolution point of view the ambiguity is
> gone
> > > then.
> > >
> > > Needless to say that these mandatory attributes will be removed once
> the
> > > OSGi API is released and at 1.0
> > >
> > > Cheers,
> > >
> > > David
> > >
> > > [1]
> > >
> > http://felix.apache.org/documentation/development/
> provisional-osgi-api-policy.html
> > <
> > http://felix.apache.org/documentation/development/
> provisional-osgi-api-policy.html
> > >
> >
>



-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Bram Pouwelse <br...@pouwelse.com>.
I Like the simple version ( org.osgi.someapi; version="0.1";
mandatory:="provisional"; provisional="felix" ), and then I think it makes
sense to advise a bit more conservative import range like
 Import-Package: org.osgi.someapi;version="[0.1,0.2)";provisional=felix

And that also implies that the version needs to be updated when a newer
version is included in a next version.


On Fri, Dec 23, 2016 at 1:41 PM Neil Bartlett <nj...@gmail.com> wrote:

> This suggestion from David sounds like a reasonable compromise to me.
>
> I would point out that if you are building with bnd and you put a bundle
> with a mandatory attribute on your build path, then bnd will assume that
> you want to set that attribute on your import. Thus it will work fairly
> transparently. And of course if you DON’T want provisional APIs, don’t put
> provisional bundles on your build path. As the developer this is something
> that you will have full control over.
>
> Neil
>
> > On 23 Dec 2016, at 12:36, David Bosschaert <da...@gmail.com>
> wrote:
> >
> > Hi all,
> >
> > On 23 December 2016 at 12:13, Jan Willem Janssen <
> > janwillem.janssen@luminis.eu <ma...@luminis.eu>>
> wrote:
> >
> >>
> >>> On 23 Dec 2016, at 12:30, David Bosschaert <david.bosschaert@gmail.com
> >
> >> wrote:
> >>>
> >>> Hi Bram,
> >>>
> >>> On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com> wrote:
> >>>
> >>>>> 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).
> >>>>
> >>>>
> >>> There is a somewhat unwritten convention that API < 1.0 is
> 'experimental'
> >>> and therefore that exported API in versions [0.0, 1.0) does not follow
> >>> semantic versioning... Basically what you're signing up to by using
> this
> >>> 'provisional' API which has a version < 1.0 is that anything could
> >> change…
> >>
> >> Why not go for the empty version of 0.0.0 for such APIs then? I
> understand
> >> that there’s a need to express the fact that an API is still actively
> being
> >> developed and not yet final, but using versions in the range of [0,1)
> would
> >> make stuff just more complex given that they loose all semantics and are
> >> only “informational” for humans to parse and comprehend.
> >>
> >>
> > Whether we stick with 0.0.0 or allow different versions between [0.0.0,
> > 1.0) this would still suffer from Bram's point that if multiple projects
> do
> > releases that contain provisional API you don't know which one you'll get
> > from the resolver.
> >
> > This could be fixed by using mandatory attributes on the exported
> package.
> > It is a somewhat rarely used feature of OSGi. Currently the document at
> [1]
> > says to use the following decoration on the exported package:
> >  Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status";
> > status="provisional"
> >
> > This means that importers can only import this package if they expressly
> > add this to the import:
> >  Import-Package: ,org.osgi.someapi;version="[0.0,1)";status="provisional"
> >
> > We could specialize this a little bit to indicate what project the
> version
> > is from
> >  org.osgi.someapi; version="0.1"; mandatory:="status,implemetation";
> > status="provisional"; implementation="felix"
> > or maybe simply:
> >  org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional
> > ="felix"
> >
> > Then the import would become:
> >  Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix
> > which means that the import will only resolve to the 'felix' variant of
> the
> > provisional API. So from a resolution point of view the ambiguity is gone
> > then.
> >
> > Needless to say that these mandatory attributes will be removed once the
> > OSGi API is released and at 1.0
> >
> > Cheers,
> >
> > David
> >
> > [1]
> >
> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
> <
> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
> >
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Neil Bartlett <nj...@gmail.com>.
This suggestion from David sounds like a reasonable compromise to me.

I would point out that if you are building with bnd and you put a bundle with a mandatory attribute on your build path, then bnd will assume that you want to set that attribute on your import. Thus it will work fairly transparently. And of course if you DON’T want provisional APIs, don’t put provisional bundles on your build path. As the developer this is something that you will have full control over.

Neil

> On 23 Dec 2016, at 12:36, David Bosschaert <da...@gmail.com> wrote:
> 
> Hi all,
> 
> On 23 December 2016 at 12:13, Jan Willem Janssen <
> janwillem.janssen@luminis.eu <ma...@luminis.eu>> wrote:
> 
>> 
>>> On 23 Dec 2016, at 12:30, David Bosschaert <da...@gmail.com>
>> wrote:
>>> 
>>> Hi Bram,
>>> 
>>> On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com> wrote:
>>> 
>>>>> 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).
>>>> 
>>>> 
>>> There is a somewhat unwritten convention that API < 1.0 is 'experimental'
>>> and therefore that exported API in versions [0.0, 1.0) does not follow
>>> semantic versioning... Basically what you're signing up to by using this
>>> 'provisional' API which has a version < 1.0 is that anything could
>> change…
>> 
>> Why not go for the empty version of 0.0.0 for such APIs then? I understand
>> that there’s a need to express the fact that an API is still actively being
>> developed and not yet final, but using versions in the range of [0,1) would
>> make stuff just more complex given that they loose all semantics and are
>> only “informational” for humans to parse and comprehend.
>> 
>> 
> Whether we stick with 0.0.0 or allow different versions between [0.0.0,
> 1.0) this would still suffer from Bram's point that if multiple projects do
> releases that contain provisional API you don't know which one you'll get
> from the resolver.
> 
> This could be fixed by using mandatory attributes on the exported package.
> It is a somewhat rarely used feature of OSGi. Currently the document at [1]
> says to use the following decoration on the exported package:
>  Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status";
> status="provisional"
> 
> This means that importers can only import this package if they expressly
> add this to the import:
>  Import-Package: ,org.osgi.someapi;version="[0.0,1)";status="provisional"
> 
> We could specialize this a little bit to indicate what project the version
> is from
>  org.osgi.someapi; version="0.1"; mandatory:="status,implemetation";
> status="provisional"; implementation="felix"
> or maybe simply:
>  org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional
> ="felix"
> 
> Then the import would become:
>  Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix
> which means that the import will only resolve to the 'felix' variant of the
> provisional API. So from a resolution point of view the ambiguity is gone
> then.
> 
> Needless to say that these mandatory attributes will be removed once the
> OSGi API is released and at 1.0
> 
> Cheers,
> 
> David
> 
> [1]
> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html <http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Jan Willem Janssen <ja...@luminis.eu>.
> On 23 Dec 2016, at 13:36, David Bosschaert <da...@gmail.com> wrote:
> 
> Hi all,
> 
> On 23 December 2016 at 12:13, Jan Willem Janssen <
> janwillem.janssen@luminis.eu> wrote:
> 
>> 
>>> On 23 Dec 2016, at 12:30, David Bosschaert <da...@gmail.com>
>> wrote:
>>> 
>>> Hi Bram,
>>> 
>>> On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com> wrote:
>>> 
>>>>> 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).
>>>> 
>>>> 
>>> There is a somewhat unwritten convention that API < 1.0 is 'experimental'
>>> and therefore that exported API in versions [0.0, 1.0) does not follow
>>> semantic versioning... Basically what you're signing up to by using this
>>> 'provisional' API which has a version < 1.0 is that anything could
>> change…
>> 
>> Why not go for the empty version of 0.0.0 for such APIs then? I understand
>> that there’s a need to express the fact that an API is still actively being
>> developed and not yet final, but using versions in the range of [0,1) would
>> make stuff just more complex given that they loose all semantics and are
>> only “informational” for humans to parse and comprehend.
>> 
>> 
> Whether we stick with 0.0.0 or allow different versions between [0.0.0,
> 1.0) this would still suffer from Bram's point that if multiple projects do
> releases that contain provisional API you don't know which one you'll get
> from the resolver.
> 
> This could be fixed by using mandatory attributes on the exported package.
> It is a somewhat rarely used feature of OSGi. Currently the document at [1]
> says to use the following decoration on the exported package:
>  Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status";
> status="provisional"
> 
> This means that importers can only import this package if they expressly
> add this to the import:
>  Import-Package: ,org.osgi.someapi;version="[0.0,1)";status="provisional"
> 
> We could specialize this a little bit to indicate what project the version
> is from
>  org.osgi.someapi; version="0.1"; mandatory:="status,implemetation";
> status="provisional"; implementation="felix"
> or maybe simply:
>  org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional
> ="felix"
> 
> Then the import would become:
>  Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix
> which means that the import will only resolve to the 'felix' variant of the
> provisional API. So from a resolution point of view the ambiguity is gone
> then.

Good compromise.

> Needless to say that these mandatory attributes will be removed once the
> OSGi API is released and at 1.0

You should want to do that anyways given that the API is no longer considered
provisional ;)

--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814


My world is something with Amdatu and Apache

Luminis Technologies
Churchillplein 1
7314 BZ  Apeldoorn
+31 88 586 46 00

https://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by David Bosschaert <da...@gmail.com>.
Hi all,

On 23 December 2016 at 12:13, Jan Willem Janssen <
janwillem.janssen@luminis.eu> wrote:

>
> > On 23 Dec 2016, at 12:30, David Bosschaert <da...@gmail.com>
> wrote:
> >
> > Hi Bram,
> >
> > On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com> wrote:
> >
> >>> 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).
> >>
> >>
> > There is a somewhat unwritten convention that API < 1.0 is 'experimental'
> > and therefore that exported API in versions [0.0, 1.0) does not follow
> > semantic versioning... Basically what you're signing up to by using this
> > 'provisional' API which has a version < 1.0 is that anything could
> change…
>
> Why not go for the empty version of 0.0.0 for such APIs then? I understand
> that there’s a need to express the fact that an API is still actively being
> developed and not yet final, but using versions in the range of [0,1) would
> make stuff just more complex given that they loose all semantics and are
> only “informational” for humans to parse and comprehend.
>
>
Whether we stick with 0.0.0 or allow different versions between [0.0.0,
1.0) this would still suffer from Bram's point that if multiple projects do
releases that contain provisional API you don't know which one you'll get
from the resolver.

This could be fixed by using mandatory attributes on the exported package.
It is a somewhat rarely used feature of OSGi. Currently the document at [1]
says to use the following decoration on the exported package:
  Export-Package: org.osgi.someapi; version="0.1"; mandatory:="status";
status="provisional"

This means that importers can only import this package if they expressly
add this to the import:
  Import-Package: ,org.osgi.someapi;version="[0.0,1)";status="provisional"

We could specialize this a little bit to indicate what project the version
is from
  org.osgi.someapi; version="0.1"; mandatory:="status,implemetation";
status="provisional"; implementation="felix"
or maybe simply:
  org.osgi.someapi; version="0.1"; mandatory:="provisional"; provisional
="felix"

Then the import would become:
  Import-Package: ,org.osgi.someapi;version="[0.0,1)";provisional=felix
which means that the import will only resolve to the 'felix' variant of the
provisional API. So from a resolution point of view the ambiguity is gone
then.

Needless to say that these mandatory attributes will be removed once the
OSGi API is released and at 1.0

Cheers,

David

[1]
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Jan Willem Janssen <ja...@luminis.eu>.
> On 23 Dec 2016, at 12:30, David Bosschaert <da...@gmail.com> wrote:
> 
> Hi Bram,
> 
> On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com> wrote:
> 
>>> 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).
>> 
>> 
> There is a somewhat unwritten convention that API < 1.0 is 'experimental'
> and therefore that exported API in versions [0.0, 1.0) does not follow
> semantic versioning... Basically what you're signing up to by using this
> 'provisional' API which has a version < 1.0 is that anything could change…

Why not go for the empty version of 0.0.0 for such APIs then? I understand
that there’s a need to express the fact that an API is still actively being
developed and not yet final, but using versions in the range of [0,1) would
make stuff just more complex given that they loose all semantics and are
only “informational” for humans to parse and comprehend.

--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814


My world is something with Amdatu and Apache

Luminis Technologies
Churchillplein 1
7314 BZ  Apeldoorn
+31 88 586 46 00

https://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Bram Pouwelse <br...@pouwelse.com>.
In that case I don't like the idea of released bundles using API versions <
1. What if some other bundle is providing that same package there would be
no way for te resolver to know that those packages are actually not
compatible.

On Fri, Dec 23, 2016 at 12:30 PM David Bosschaert <
david.bosschaert@gmail.com> wrote:

> Hi Bram,
>
> On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com> wrote:
>
> > > 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).
> >
> >
> There is a somewhat unwritten convention that API < 1.0 is 'experimental'
> and therefore that exported API in versions [0.0, 1.0) does not follow
> semantic versioning... Basically what you're signing up to by using this
> 'provisional' API which has a version < 1.0 is that anything could
> change...
>
> Cheers,
>
> David
>

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by David Bosschaert <da...@gmail.com>.
Hi Bram,

On 23 December 2016 at 11:02, Bram Pouwelse <br...@pouwelse.com> wrote:

> > 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).
>
>
There is a somewhat unwritten convention that API < 1.0 is 'experimental'
and therefore that exported API in versions [0.0, 1.0) does not follow
semantic versioning... Basically what you're signing up to by using this
'provisional' API which has a version < 1.0 is that anything could change...

Cheers,

David

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Bram Pouwelse <br...@pouwelse.com>.
> 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

Re: Proposal for slight amendment to Felix provisional OSGi API policy

Posted by Christian Schneider <ch...@die-schneider.net>.
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 <da...@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>