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 Jencks <da...@yahoo.com> on 2014/05/27 18:49:44 UTC
[RESULT][VOTE] Policy change for use of unreleased (spec) apis
4 +1 from PMC members, no other votes. I'll see if I can update the site without mishaps :-)
thanks
david jencks
On May 22, 2014, at 5:57 AM, Karl Pauls <ka...@gmail.com> wrote:
> +1
>
> regards,
>
> Karl
>
>
> On Thu, May 22, 2014 at 2:53 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>
>> +1
>>
>> -> richard
>>
>> On 5/20/14, 13:01 , David Jencks wrote:
>>
>>> Following some dev list discussion, proposal is to change
>>> http://felix.apache.org/documentation/development/
>>> provisional-osgi-api-policy.html to this (markdown source):
>>>
>>>
>>> ------------------------------------------------------------
>>> --------------------------
>>>
>>> The OSGi Alliance exposes provisional API that may or may not become part
>>> of future OSGI specifications. This policy explains how and when Felix
>>> subprojects may relate to such API. Provisional OSGi API refers to anything
>>> in the `org.osgi.*` package namespace that is not part of a final released
>>> specification.
>>>
>>> ## Policy
>>> 1. No Felix release may contain or refer to provisional OSGI API.
>>> 1. Provisional API may be included and used in unreleased source code,
>>> however the API must be part of a final released OSGI specification before
>>> this Felix source may be released.
>>>
>>> 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of
>>> provisional api may be released with these modifications:
>>>
>>> 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*`
>>> package name space; this effectively makes it provisional Felix API.
>>> 1. All Felix provisional API must be marked as deprecated.
>>> 1. All Felix provisional API exported from bundles should be exported
>>> with a mandatory attribute of `status="provisional"`.
>>>
>>> ## Discussion
>>>
>>> The first goal of this policy is to completely avoid using provisional
>>> OSGi API in released Felix projects given the potential confusion and
>>> questions by doing so. The second goal is to make the existence of any
>>> released Felix provisional API completely obvious to downstream users and
>>> make it difficult for them to use it unknowingly. However, any such release
>>> is likely to involve numerous problems such as incorrect semantic
>>> versioning or version mismatch between the provisional and eventual OSGI
>>> release and bundle version inflation if the Felix provisional api is
>>> removed after the OSGI API is released.
>>>
>>> As an example, to provisionally export the `org.apache.felix.service.metatype`
>>> package, the
>>> `Export-Package` statement would look something like this:
>>>
>>> :::xml
>>> <Export-Package>
>>> org.apache.felix.service.metatype; version="0.1";
>>> mandatory="status"; status="provisional"
>>> </Export-Package>
>>>
>>> When working with new OSGI specifications, constructing a Felix
>>> provisional API will likely result in parallel package structures between
>>> the provisional OSGi and Felix APIs. When working with existing
>>> specifications, it may be necessary to create extensions to existing OSGi
>>> interfaces in the Felix package namespace.
>>>
>>>
>>> ------------------------------------------------------------
>>> --------------------------
>>>
>>> +1 [ ] Adopt this replacement text
>>> -1 [ ] Keep the existing text
>>> 0 [ ] Don't care
>>>
>>> Vote open for 72 hours or until I can get enough people to vote :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>
>
>
> --
> Karl Pauls
> karlpauls@gmail.com
> http://twitter.com/karlpauls
> http://www.linkedin.com/in/karlpauls
> https://profiles.google.com/karlpauls
Re: [RESULT][VOTE] Policy change for use of unreleased (spec) apis
Posted by David Jencks <da...@yahoo.com>.
I fixed the capitalization of OSGi (after I looked it up \-) and can't figure out how to get the sublist ("these modifications:") to render properly. I'll try to find some advice on the latter point….
david jencks
On May 27, 2014, at 9:49 AM, David Jencks <da...@yahoo.com> wrote:
> 4 +1 from PMC members, no other votes. I'll see if I can update the site without mishaps :-)
>
> thanks
> david jencks
>
> On May 22, 2014, at 5:57 AM, Karl Pauls <ka...@gmail.com> wrote:
>
>> +1
>>
>> regards,
>>
>> Karl
>>
>>
>> On Thu, May 22, 2014 at 2:53 PM, Richard S. Hall <he...@ungoverned.org>wrote:
>>
>>> +1
>>>
>>> -> richard
>>>
>>> On 5/20/14, 13:01 , David Jencks wrote:
>>>
>>>> Following some dev list discussion, proposal is to change
>>>> http://felix.apache.org/documentation/development/
>>>> provisional-osgi-api-policy.html to this (markdown source):
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> --------------------------
>>>>
>>>> The OSGi Alliance exposes provisional API that may or may not become part
>>>> of future OSGI specifications. This policy explains how and when Felix
>>>> subprojects may relate to such API. Provisional OSGi API refers to anything
>>>> in the `org.osgi.*` package namespace that is not part of a final released
>>>> specification.
>>>>
>>>> ## Policy
>>>> 1. No Felix release may contain or refer to provisional OSGI API.
>>>> 1. Provisional API may be included and used in unreleased source code,
>>>> however the API must be part of a final released OSGI specification before
>>>> this Felix source may be released.
>>>>
>>>> 1. Although it is STRONGLY NOT RECOMMENDED, modified versions of
>>>> provisional api may be released with these modifications:
>>>>
>>>> 1. Any provisional OSGi API must be recreated in the `org.apache.felix.*`
>>>> package name space; this effectively makes it provisional Felix API.
>>>> 1. All Felix provisional API must be marked as deprecated.
>>>> 1. All Felix provisional API exported from bundles should be exported
>>>> with a mandatory attribute of `status="provisional"`.
>>>>
>>>> ## Discussion
>>>>
>>>> The first goal of this policy is to completely avoid using provisional
>>>> OSGi API in released Felix projects given the potential confusion and
>>>> questions by doing so. The second goal is to make the existence of any
>>>> released Felix provisional API completely obvious to downstream users and
>>>> make it difficult for them to use it unknowingly. However, any such release
>>>> is likely to involve numerous problems such as incorrect semantic
>>>> versioning or version mismatch between the provisional and eventual OSGI
>>>> release and bundle version inflation if the Felix provisional api is
>>>> removed after the OSGI API is released.
>>>>
>>>> As an example, to provisionally export the `org.apache.felix.service.metatype`
>>>> package, the
>>>> `Export-Package` statement would look something like this:
>>>>
>>>> :::xml
>>>> <Export-Package>
>>>> org.apache.felix.service.metatype; version="0.1";
>>>> mandatory="status"; status="provisional"
>>>> </Export-Package>
>>>>
>>>> When working with new OSGI specifications, constructing a Felix
>>>> provisional API will likely result in parallel package structures between
>>>> the provisional OSGi and Felix APIs. When working with existing
>>>> specifications, it may be necessary to create extensions to existing OSGi
>>>> interfaces in the Felix package namespace.
>>>>
>>>>
>>>> ------------------------------------------------------------
>>>> --------------------------
>>>>
>>>> +1 [ ] Adopt this replacement text
>>>> -1 [ ] Keep the existing text
>>>> 0 [ ] Don't care
>>>>
>>>> Vote open for 72 hours or until I can get enough people to vote :-)
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Karl Pauls
>> karlpauls@gmail.com
>> http://twitter.com/karlpauls
>> http://www.linkedin.com/in/karlpauls
>> https://profiles.google.com/karlpauls
>