xml-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane Curcuru/CAM/Lotus <shane_curc...@us.ibm.com>
Subject Re: Process for making changes to xml-commons?
Date Thu, 24 Oct 2002 14:58:53 GMT
Hmmm - formally, we don't have a detailed strategy.  Active interest in 
xml-commons has still been fairly light, and although I think our 
cataloger is quite nifty, I haven't heard lots of talk of folks using it 
directly (at least not on commons-dev@xml).  I'm pretty sure there aren't 
any direct automated builds that are dependent on your APIs currently 
(i.e. GUMP/forrestt/etc) so that shouldn't be a problem.

Are your changes backwards compatible?  If so, and you've done due 
dilligence in testing them, then I say check them in.  (Somehow I have the 
feeling that you know what you're doing with the cataloger...  8-)  Let me 
know if you want to work on setting up some automated tests for the 
resolver in the future; I've been hoping one day to be able to integrate 
Xalan's org.apache.qetest testing harness into xml-commons and share it.

If they aren't backwards compatible, then send a note to the list 
describing the changes and what user-code will have to change to match up 
and wait for responses.  If no-one complains in about a week, check in 

All IMO.

Hey!  Check out http://jakarta.apache.org/builds/gump/latest/xref.html and 
follow the xml-commons-resolver link to eventually the definition at 
http://jakarta.apache.org/builds/gump/latest/module_xml-cocoon2.html which 
means that someone in xml-cocoon2 land does have a <option.../> dependency 
on the resolver.  Hence if you're making incompatible API changes, you 
should email cocoon-dev@xml.apache.org and ask there for comments.

- Shane

View raw message