next level of freedesktop.org

[Daniel Veillard]

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

-- 
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/