<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">I maintain the Eclipse project's SWT
Browser control, which last year switched from using Gecko to WebKitGTK
(1.2 at the time).  The main motive for this transition was a desire
to use a native renderer that would not break us with every release (Gecko
was doing this).  With WebKitGTK 1.4 now out there I see that the
API has been reasonably preserved but binary compatibility has not, and
as a result our latest service release from three months ago already fails
on Linux distros that ship WebKitGTK 1.4, because our library was compiled
against 1.2.  We're now looking at shipping two versions of our webkit
library, one compiled against WebKitGTK 1.2 and the other against 1.4,
in order to support older and newer linux releases.  My question is,
is ABI breakage going to be a recurring pattern with each WebKitGTK release?</font>
<br>
<br><font size=2 face="sans-serif">Most of the other libraries that SWT
uses (gtk2, atk, glib, etc.) have not broken us in 10 years of use, as
they maintain API and ABI compatibility as a policy.  Maintaining
ABI compatibility may not matter when a client app is being shipped with
a linux distro, but it greatly affects software that users download rather
than using a version that's bundled with their OS.  I assume there
are other apps out there that also become broken by changes like this (?).
 Is there any will to maintain binary compatibility in future WebKitGTK
releases?  To do so would do a great service to your client apps (or
at least one of them :-) ).</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">Grant</font>
<br>