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. 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 <[email protected]> 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 <[email protected]> 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<[email protected]> 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 >>>>>> >>>>>> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
