Hi, Am 23.09.2010 16:05, schrieb Richard S. Hall: > On 9/23/10 2:49, Felix Meschberger wrote: >> Hi, >> >> Maybe too late, but anyways. > > No, it's not too late, since we still need to define our policy with > respect to provisional OSGi APIs...so we need everyone's opinion on this > to come to consensus. > > Felix, this will likely impact you in odd ways if you continue to > provide the Config Admin RI. For example, if you implement the future > spec changes, if you plan to release it so people can play with it then > you'll need to put the changed API in org.apache.felix.cm namespace.
Hmm, yes. Unless OSGi decides otherwise I am fine with continuing supplying the RI. > > If you don't plan on releasing it until the spec is final, then I > suppose org.osgi namespace is fine, but we should still probably mark > them the same way. Actually we should do this regardless of whether we release or not, but maybe it would be good to release. > > I guess this last point is also worthwhile to discuss. I think our > policy can differentiate between what we release and what we experiment > with, right? The policy for releases should be "no provisional OSGi > API", while for playing around in trunk or a sandbox is different, > right? Or no? I think whatever we have in SVN is kind of publicly available and thus I think we should do experiments in our own namespace even if we don't release. Regards Felix > >> I am probably fine with #3. >> >> I particularly like the key argument for using mandatory attributes: >> "clearly state that you know what you are doing". > > Ok, that's two for #3. :-) > > -> richard > >> Regards >> Felix >> >> Am 22.09.2010 21:48, schrieb Richard S. Hall: >>> 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<[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 >>>>>>> >>>>>> >
