felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Handling of provisional OSGi API
Date Wed, 22 Sep 2010 06:29:15 GMT
Do you plan to release gogo as 0.6.1 as indicated in JIRA ?
Given the change is fully incompatible, I'd at least bump the minor version ...

On Mon, Sep 20, 2010 at 17:50, Richard S. Hall <heavy@ungoverned.org> wrote:
>  On 9/20/10 11:21, Derek Baum wrote:
>> 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?
> It sounds like we have consensus, so we can probably just move forward.
> -> richard
>> 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
>>>>>      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
>>>>> 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

Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA

View raw message