next level of freedesktop.org
veillard at redhat.com
Fri Jul 18 04:03:58 EEST 2003
On Thu, Jul 17, 2003 at 10:32:09AM -0400, Jody Goldberg wrote:
> On Thu, Jul 17, 2003 at 03:01:47PM +0200, Waldo Bastian wrote:
> > It can now happen that a new GNOME 2.7 requires a new libxslt 2.7.8 but that
> > for some reason libxslt 2.7.8 breaks KDE 3.5. Sure, we all try to stay
> > backwards (binary) compatible, but bugs do happen and maybe KDE 3.5 relied on
> > some undocumented behavior.
IIRC this somewhat happened no ;-)
Except early testing before releases I don't see how to avoid such problems.
We have seen this with programs and libraries using non-public entry point
of glibc, and either you can fix the callers and make a synchronized new
release or you have to keep a compatibility library.
> This raises an interesting issue. There are a few libs like
> libxml/libxslt that are used fairly universally. Does it make sense
> to explicitly move them into the nascent project ? IMHO, yes. The
> more explicitly common code the better.
The point IMHO is rather common testing. I'm pretty sure libxml2/libxslt
code I commit will be tested immediately by the Gnome users, and will
be tested by my Windows user base after the next official release, but
sometime it takes a few releases before I get noticed of a KDE breakage.
My conclusion is that the key point is homogeneous and as early as
possible testing, one of the thing to avoid is for example to keep
a separate copy of such lib into another project CVS base unless it's
updated on a daily basis.
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the xdg