+1 for #1 regards,
Karl On Sun, Sep 19, 2010 at 6:27 PM, 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 >>> > -- Karl Pauls [email protected]
