[webkit-gtk] ABI compatibility between releases

[Grant Gayed]

I understand the tension between maintaining compatibility and moving 
forward, SWT/Eclipse also lives in such a world.  However I think GTK 
balanced this well by maintaining compatibility throughout each major 
release, and then as the burden of doing so became too painful, creating a 
new major release.  The GTK devs may feel that they kept the 2.x stream 
alive for too long (possibly true), but even if they had cut it off 
earlier, this would not have caused a problem for clients because Linux 
distros continue to ship GTK libs from each major stream.  As a result 
apps written for GTK 1.x can still run today, even though GTK abandoned 
this codebase long ago.  Eclipse is doing something similar: its 3.x 
stream has maintained compatibility for 8 years, but as this has become 
too constraining, the 4.x stream has emerged.  My hope was that WebKitGTK 
would have a similar approach, since other similar libs, including the 
other WebKit ports we use, maintain compatibility within major revisions 
which last for at least a few years.

Thanks for reading,
Grant





Xan <xan.lopez at gmail.com> 
05/05/2011 06:53 PM

To
Grant Gayed/Ottawa/IBM at IBMCA
cc
webkit-gtk at lists.webkit.org, Silenio Quarti/Ottawa/IBM at IBMCA
Subject
Re: [webkit-gtk] ABI compatibility between releases






On Thu, May 5, 2011 at 3:09 PM, Grant Gayed <Grant_Gayed at ca.ibm.com> 
wrote:
> 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 :-) ).

We understand changing the ABI creates problems for some people, so we
don't do it lightly. In this particular case a series of reasons
converged that convinced us that it was the right thing to do at that
moment. Other than that we still stick to our policy of gradually
removing deprecated functionality relatively quick (after two major
stable releases), so if you are expecting frozen-in-time-for-10-years
stuff you are probably going to be disappointed again in the future.
It's my understanding that the maintainers of the libraries you
mention think keeping things stagnant for so long was a mistake, and
that a better compromise must be reached between moving forward and
backwards compatibility, so I don't think we are alone in this kind of
thinking.

Hope that helps,

Xan


>
> Thanks,
> Grant
>
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20110506/2f578fbd/attachment.html>