Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4C9639D9.1010809@ungoverned.org>
References: <4C9398BF.1040700@ungoverned.org>
	<4C94F821.3040601@gmail.com>
	<4C9639D9.1010809@ungoverned.org>
Date: Mon, 20 Sep 2010 16:21:59 +0100
Message-ID: <AANLkTimSukV5GjJrMRi3S3K0LQfibXOCwBjiJ9aq8vuw@mail.gmail.com>
Subject: Re: Handling of provisional OSGi API
From: Derek Baum <derek.baum@paremus.com>
To: dev <dev@felix.apache.org>
Content-Type: multipart/alternative; boundary=000325559ee64581ec0490b2798e

--000325559ee64581ec0490b2798e
Content-Type: text/plain; charset=ISO-8859-1

I also favor #1.

When we apply this to gogo, it will mean removing the draft RFC-147 API from
the org.osgi.service.command namespace and moving it to a felix namespace.

We actually already did this for the gogo-0.6 release, but then reverted the
change in the trunk, as it broke many command providers who imported
org.osgi.service.command. Back then we didn't have a policy for supporting
draft OSGi APIs, but now it seems like we've agreed on #1. Do we need a
vote?

Derek


On 19 September 2010 17:27, Richard S. Hall <heavy@ungoverned.org> wrote:

>  On 9/18/10 10:34, Felix Meschberger wrote:
>
>> Hi,
>>
>> While I understand (and certainly don't underestimate the consequences
>> of) the drawbacks of option (1) I still think it is the better option.
>>
>> At the time the OSGi releases the official API, we can still keep our
>> internal API for certain period of time thus supporting both API, if we
>> so wish.
>>
>
> From my point of view we should just export the packages with mandatory
> attributes and make it clear they will change when the API goes final. For
> framework, I wouldn't plan to provide any ongoing support for provisional
> API. However, I don't think we need to mandate a global Felix policy for
> this and subprojects can choose to support two APIs if they want.
>
> -> richard
>
>
>
>  Regards
>> Felix
>>
>> Am 17.09.2010 18:35, schrieb Richard S. Hall:
>>
>>>  For a long time, we've played a little fast and loose with our handling
>>> of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo 0.6.0
>>> releases, we've started to evolve a policy on how to handle this, but
>>> nothing has been decided concretely. This is problematic since it leads
>>> different people to different decisions. Thus, its about time we defined
>>> our policy on this.
>>>
>>> So, what's the issue?
>>>
>>> Provisional OSGi API is not official. Further, provisional package
>>> content is evolving and these changes are not always made readily
>>> available by the OSGi Alliance. Even though some of us are members of
>>> the OSGi Alliance, we are not necessarily at liberty to disclose changes
>>> to internal RFCs.
>>>
>>> So, what can we do about it?
>>>
>>> I see two potential [reasonable] policies from which we could choose:
>>>
>>>   1. Always use the org.apache.felix package namespace for provisional
>>>      OSGi API until the spec goes final.
>>>   2. Use the org.osgi package namespace while the provisional API is in
>>>      development, but only expose what has been publicly made available
>>>      by the OSGi Alliance.
>>>
>>> Both approaches have their drawbacks.
>>>
>>> The benefit of (1) is that the legal/IP/etiquette issues and/or concerns
>>> are reduced to those associated with normal open source development. For
>>> completely new development, like Gogo, this would all happen in non-OSGi
>>> packages, while changes to existing packages would need to be done in
>>> subclasses in non-OSGi packages. One downside of (1) is that it will
>>> always result in a package name change at the end that will break
>>> existing clients. For this reason, such experimental packages should be
>>> exported with mandatory attributes to warn potential clients.
>>>
>>> The benefit of (2) is that the package namespace is more consistent. The
>>> downside of (2) is that it is a IP/legal/etiquette gray area as to
>>> whether or not we can do official releases of subprojects containing
>>> provisional OSGi API. Even if we do not modify the API, it still is
>>> potentially confusing to our users who are getting an "official" release
>>> from us of a subproject containing these "unofficial" bytes. At a
>>> minimum we would also need to use deprecated tags and/or mandatory
>>> attributes to warn people. Even then, it still raises issues since we
>>> aren't at liberty to evolve the packages freely to include OSGi
>>> internal, non-public RFC updates, nor extensions for potential feedback
>>> into the RFC. In those cases, we would still need to resort to putting
>>> stuff in org.apache.felix packages and renaming later once the changes
>>> become public, which would also be problematic for clients. Also, you
>>> have to consider the case where the RFC is abandoned, in which case if
>>> we still find it useful, we'll be forced to change our package names.
>>>
>>>  From my point of view, approach (1) might not be awesome, but it results
>>> in a simpler process than (2). So, I'd recommend (1). If the majority
>>> prefers (2), then we can do that (although I think we'll have to run the
>>> decision by the board first).
>>>
>>> Thoughts?
>>>
>>> ->  richard
>>>
>>>

--000325559ee64581ec0490b2798e--