How about firefox 3.6 in Fedora 12 ?

[Braden McDaniel]

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 at endoframe.com>