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

[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

[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

[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

[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

[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

[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

[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

["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

[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

[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

["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

[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

[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

[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