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
