On 17 Sep 2010, at 22:27 , Richard S. Hall wrote: > On 9/17/10 12:54, Marcel Offermans wrote: >> On 17 Sep 2010, at 21:12 , Richard S. Hall wrote: >>> On 9/17/10 12:11, Richard S. Hall wrote: >>>> On 9/17/10 11:36, Marcel Offermans wrote: >>>>> On 17 Sep 2010, at 18:35 , Richard S. Hall wrote: >>>>> >>>>>> 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). >>>>> I prefer (1) too. >>>>> >>>>> I could see us combine (1) with (2), releasing implementations with both >>>>> our own APIs which gives us the freedom to experiment with a new API >>>>> whilst still "supporting what's provided by public releases of draft >>>>> specs. >>>> However, this doesn't avoid the IP grey of releasing "unofficial" APIs in >>>> our "official" releases. >> Does the OSGi alliance disallow the inclusion of these "unofficial" APIs? >> >>>> Effectively, option (2) is a hybrid approach, since we couldn't make >>>> modifications in the provisional API unless it were available in a public >>>> spec snapshot, so any modifications would have to be done in felix package >>>> namespace. Which sort of makes (2) the worst of both worlds. >> >> Well, if the snapshots are so outdated that it does not make sense to >> implement them, then we should not even try. In that case, just stick to (1). > > Sometimes it is not an issue of being out of date. If we want to implement a > feature for potential inclusion into an RFC, then we run into the same issue > if we add the feature to an existing OSGi API (whether it is provisional or > not).
I think that the versioning policy that the OSGi Alliance uses leaves us little room here, so again we should probably go to (1). I mean, let's say that spec 1.6 is the latest stable release and there is a draft for 1.7 then there is no number in between that we could use to indicate we're past 1.6 but not yet at 1.7. >> I guess the other point would be for the OSGi Alliance to just develop new >> RFCs out in the open, but as long as they're not, it's probably safer to >> ignore them if it could cause problems otherwise. > > Well, we don't want to ignore them since we want to implement the provisional > specs and get experience with them. It is just difficult since our downstream > users have no way of knowing what is official OSGi API and what isn't if we > ship with provisional and/or modified org.osgi packages. We can always simply not release experimental code / provisional specs, keep them in an experimental branch if we want to still maintain an existing stable release. > Even following option (1), it's still a tricky balancing act, especially in > cases where we might actually provide the RI, such as Gogo or CM. But this is > more difficult for us since we release early and often as opposed to Eclipse > which releases yearly. As long as we release in our own namespace, I don't see the problem. Let's say we do an experimental release of CM. We would release it as a bundle exporting org.apache.felix.service.cm. The only "tricky" part is that consumer bundles would have to use the packages in our namespace, so it would probably mean they'd have to be written specifically for our implementation. But that's probably the best way to experiment safely anyway. Greetings, Marcel
