felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Handling of provisional OSGi API
Date Wed, 22 Sep 2010 19:48:06 GMT
  On 9/22/10 14:44, Richard S. Hall wrote:
>  Hopefully, I can get some quick feedback on this since I want to do a 
> release...
> Guillaume and I were discussing alternatives to a mandatory attribute. 
> An alternative idea was mark all provisional API as deprecated, so 
> clients get warnings. What are people's thoughts on the two approaches?
>   1. The benefit of using mandatory attributes on provisional API is
>      that you have to explicitly "opt in" to use it so no one can ever
>      claim they didn't know it was provisional.
>   2. The benefit of using deprecated tags is that it works more
>      smoothly with tooling and at still does give some sort of warning
>      notice, although less direct.
> Personally, i still favor using mandatory attributes, because I think 
> it better captures our use case. But, I'd like to hear what other 
> people think.

Tom Watson (of Equinox fame) pointed out that using both is probably the 
best option because only using mandatory attributes doesn't address 
Require-Bundle, which could use the packages freely without opting in. 
Otherwise, he feels the same way I do, that mandatory attributes are a 
good idea (just like for split packages), because you really need to 
know what you are doing to use the packages...

Given the fact that I really need to get a release of Gogo trunk out the 
door, I'm just going to push forward for now with what we have in trunk, 
which is using mandatory attributes. We can continue to refine our 
policy and when we are done, we can do another release to reflect it 
even if it means doing another one next week.

So, to summarize, we now have three options:

   1. Just mandatory attributes.
   2. Just deprecated tags.
   3. Both.

After Tom's arguments, I'm probably now leaning toward #3.

-> richard

> Quickly. :-)
> -> richard
> On 9/22/10 9:19, Richard S. Hall wrote:
>>  On 9/22/10 6:16, Guillaume Nodet wrote:
>>> I'm also not convinced by the mandatory attribute.  I do understand
>>> the value, but it may cause a lot of burden on our users for not much.
>> If you have another recommendation for making it 100% clear to our 
>> users that these packages will not be supported in the future, then 
>> speak up. It's not that I want to use mandatory attributes, it's that 
>> I don't want to be taken to task in the future for throwing away the 
>> API. In that regard, I think there is benefit to using it since 
>> people have to go out of their way to use it.
>> Regarding the version number, I was using 0.6.1 because it is only a 
>> maintenance release as compared to 0.6.0. The completely incompatible 
>> change was from 0.4.0 to 0.6.0, no? Or are you specifically referring 
>> to the mandatory attribute? If so, I don't have an issue with it 
>> being 0.8.0 if you think the mandatory attribute warrants it, but I 
>> don't really think that constitutes a breaking code 
>> change...certainly a breaking metadata change.
>> -> richard
>>>   Mandatory attributes are not very common and the tooling might not be
>>> prepared to handle those gracefully.  For example, I've just hit a big
>>> problem with karaf integration tests that use pax-exam, because the
>>> mandatory attribute it not automatically added, so all test bundles
>>> were failing during resolution ...
>>> I've fixed that, but an average user will be in a real trouble if 
>>> hitting this.
>>> On Wed, Sep 22, 2010 at 08:29, Guillaume Nodet<gnodet@gmail.com>  
>>> wrote:
>>>> 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
>>>>>>>>> this, but
>>>>>>>>> nothing has been decided concretely. This is problematic
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> available
>>>>>>>>>       by the OSGi Alliance.
>>>>>>>>> Both approaches have their drawbacks.
>>>>>>>>> The benefit of (1) is that the legal/IP/etiquette issues
>>>>>>>>> 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
>>>>>>>>> should be
>>>>>>>>> exported with mandatory attributes to warn potential
>>>>>>>>> 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
>>>>>>>>> as to
>>>>>>>>> whether or not we can do official releases of subprojects

>>>>>>>>> containing
>>>>>>>>> provisional OSGi API. Even if we do not modify the API,
>>>>>>>>> still is
>>>>>>>>> potentially confusing to our users who are getting an
>>>>>>>>> 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
>>>>>>>>> since we
>>>>>>>>> aren't at liberty to evolve the packages freely to include
>>>>>>>>> internal, non-public RFC updates, nor extensions for
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> to run
>>>>>>>>> the
>>>>>>>>> decision by the board first).
>>>>>>>>> Thoughts?
>>>>>>>>> ->     richard
>>>> -- 
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com

View raw message