On Sat, 2010-01-30 at 14:00 -0500, Mail Lists wrote:
On 01/30/2010 01:53 PM, Braden McDaniel wrote:
> On Sat, 2010-01-30 at 11:36 -0600, Rex Dieter wrote:
>> Braden McDaniel wrote:
>>
>>> On Sat, 2010-01-30 at 14:48 +0800, Liu Yu Fei Eric wrote:
>>>> Hi,
>>>>
>>>> I noticed firefox was stuck on 3.5.6 for a rather long time.
>>>> What about 3.5.7 and the recently 3.6? They are even not in koji.
>>>
>>> xulrunner-1.9.2 breaks API compatibility with 1.9.1, so downstream
>>> packages would need patching for this to happen.
>>
>> Even minor releases generally/often break ABI, requiring lots of dependent
>> package rebuilds... or is this case even worse?
>
> I said "API", and that's what I meant.
>
> At the very least, there have been subtle changes to the plug-in API
> that can cause compile failures.
>
And how many plugins are packaged by fedora ? Any?
Yes. Somewhere between a few and several.
I'd guess all the plugin dev's at the moz website state
clearly which
vers of filrefox is supported - and most want their plugins to work with
current release - 3.6.
Given that doing so can mean breaking compatibility with the previous
XULRunner release, it's probably not a good assumption that all plug-in
developers will be consistently aggressive about supporting the new
release.
Also keep in mind that I have no reason to believe that the plug-in
*ABI* has changed. Fielded binaries should be safe.
So that seems like a bad reason not to update.
So what are the couplings then that need source changes other than
plugins?
I don't know. I don't even know if
mozilla.org tracks this
meticulously.
Can someone be specific rather than hand waving API around please.
It's easy enough to diff the NPAPI headers from 1.9.1 to 1.9.2 to see
the changes. Some highlights:
* Some JNI types in function signatures have been changed to void
*, presumably to avoid pulling in JNI headers.
* C99 sized types are now used instead of XULRunner- (or NSPR-?)
specific typedefs. In some cases, this means that the new
underlying type is distinct from the old one as far as the
compiler is concerned.
I really have no idea about the extent of XULRunner API changes outside
NPAPI. But simply assuming the NPAPI changes are all there is seems
foolhardy.
--
Braden McDaniel <braden(a)endoframe.com>