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@xxxxxxxxxxxxx>
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
