Elena Litani wrote: > Joseph Kesselman wrote: > > [snip] > >>(c) Deprecate the old call, making sure the javadoc is updated to explain >>why it's deprecated and, preferably, to include or point to the >>illustration. >>(d) Give people a release cycle or two to notice and to correct their code >>before you remove the methods. > > > Sure, we can deprecate this method for the release next month and > removed it in the next Xerces release. >
Is it really necessary to do backward incompatible changes? Why not to leave it deprecated. I know it is not nice, but clients of old deprecated API will not work with newer versions, what is not too nice for API prestige. :-( I think you should keep at least binary compatibility, i.e. do not public deprecated methods, but include them in release jar. Regards, Libor -- Libor Kramolis, Software Engineer | <[EMAIL PROTECTED]> NetBeans/Sun Microsystems, XML Project | http://xml.netbeans.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
