I lean most strongly towards 2. There's no need to arbitrarily change
things, but I also don't feel too strongly about breaking backwards
compatibility if there is a compelling reason. (Of note, I have no real
stake here, as I am not using the XML:DB API.)
One thing that would help with this decision is trying to estimate how
many people actually use the API. There is a big difference between
breaking 10 applications or thousands of applications. For example,
eXist supports a number of different APIs, and one could at least
vaguely estimate their relative usage by looking at the eXist mailing
list. Also, are there any commercial (or even private) applications that
depend on XML:DB to allow switching of native XML database backends?
I do agree that deprecation, rather than outright deletion, of
interfaces is preferrable.
Per Nyfelt wrote:
> I also think it is is important to not alienate existing implementers of the
> API by introducing incompatible changes. Besides eXist and Xindice there are
> several commercial vendors as well. On the other hand, there are several
> extension to the API made by those vendors that I hope to see in the API
> (XQuery support was the last one I added heavily inspired by eXist but it is
> just an early draft). I would prefer extension, compatibility and deprecation
> rather than incompatible changes whenever possible. Of your three choices
> below I'm between 1 and 2 but closest to 2, especially if we can maintain
> backward compatibility by deprecation rather than removal of functionality.
> Best regards,