On Thu, Oct 20, 2005 at 02:27:54PM -0700, Jain, Nilesh wrote:
> I completely understand the point you have mentioned, but same time my
> real concern is for application/users of libxml2... because if
> application is depends or based on certain behavior of library, which
> changes release over release [I understand potential reasons for change]
> then how application deals with that.. do they change the application...
> or applications are usually transparent from these changes. 

  applications are usually transparent from these changes

> I guess my real question here is to understand the impact of behavior
> changes release over release on applications, and how they deal with
> that?

   make correct user code, i.e. catch errors, usually they fon't have
to deal specifically with it, a tree is way more complex than say an int,
you already have to make flexible code to deal with trees anyway.

> Or is it certain section/module of library which can vary
> depending on the underling specification interpretation change, which is
> really transparent to application... 

  that too, depends on the kind of fixes

> I am here not questioning the changes but same time trying to understand
> the impact on application, which LSB cares most... I am putting this
> question here as you have more visibility of usage and impact of these
> changes...  

  And I am answering that when I do such change I carefully think about 
how applications would react, I'm sure I said that at least a couple of time
already. I can't dump my knowledge in your brain, there is collective knowledge
on this list about libxml2 and their apps, I think they somehow at least trust
me from not breaking their apps, and I use those various tests suites
accumulated over the years to raise my level of trust on my own changes (or the
changes from other contributors).
  You can do a very dumb test like upgrading libxml2 and libxslt on a RHEL3
system to the latest RPMs I ship and chase for breakages in applications,
if you have specific application compatibilities, test them, or at least
list them.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
[EMAIL PROTECTED]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml

Reply via email to