| <?xml version='1.0' encoding='UTF-8'?> |
| <!DOCTYPE faqs SYSTEM 'dtd/faqs.dtd'> |
| <faqs title='FAQs for Developers and Prospective Contributors'> |
| <faq title="Submitting Patches"> |
| <q>I have a problem and I think I know how to fix it. How can I |
| communicate my ideas to the Xerces team? |
| </q> |
| <a> |
| <p>To maximize the probability that your ideas will grab the |
| attention of one of the Xerces developers who knows about the |
| area of the parser you're concerned with, you should follow |
| these steps: |
| </p> |
| <ol> |
| <li>Check out and build the most recent Xerces code. For |
| instructions on how to do this, see <jump |
| href="http://xml.apache.org/cvs.html">Apache XML Project CVS |
| Information</jump>. If you do this, you can confirm that your |
| bug still exists and has not been fixed since the last |
| release. |
| </li> |
| <li> |
| Write up your bug report. Include a description of your |
| system (JDK level and vendor, platform and classpath |
| contents) as well as sufficient code to reproduce the |
| problem. This code might involve XML documents, |
| accompanying grammars, and the code you are using to |
| invoke the parser or use its APIs. |
| </li> |
| <li> |
| Describe why your solution works. |
| </li> |
| <li> |
| Prepare a patch to fix Xerces code. To do this, when you |
| have applied your changes to a local copy of the most |
| recent xerces source code, do <code>cvs diff -u |
| file</code> for each file you've changed. |
| </li> |
| <li> |
| Zip (or tar) up your patches. If you send them in the |
| body of a message or bug report they are very difficult to |
| apply. |
| </li> |
| <li> |
| Submit a bug report on <jump |
| href="http://nagoya.apache.org/bugzilla">Bugzilla</jump> |
| (remembering to attach your patches and test code) |
| or, if you think your patch might need some discussion, |
| post it to the xerces-j-dev list. |
| </li> |
| </ol> |
| </a> |
| </faq> |
| <faq title="Release Preparation"> |
| <q>I am a recent committer. It has fallen to my lot to prepare a Xerces-J |
| release; how do I do this? |
| </q> |
| <a> |
| <p>You're in luck--it isn't at all difficult. Just |
| follow these steps and you'll be done in no time: |
| </p> |
| <ol> |
| <li>Ensure that the API code has been properly refreshed. |
| That is, make sure that <code>tools/xml-apis.jar</code> |
| and <code>tools/xml-apis--src.zip</code> reflect the |
| state of the branch of xml-commons that contains the API |
| set to which the parser must conform. At the time of |
| writing (March 20, 2003) this was the branch |
| <code>tck-jaxp-1_2_0</code>. |
| </li> |
| <li>Change the following files:<br/> |
| <code>build.xml</code> |
| (that is, change the <code>parser.Version</code>, |
| <code>parser.version</code>, and |
| <code>parser_version</code> properties as appropriate for the |
| release).<br/> |
| <code>docs/releases.xml</code> |
| (contributors should have updated this file as significant |
| changes/patches were applied, but the release manager should verify that |
| nothing has slipped through. |
| Also, the release manager should attempt to ensure that appropriate |
| credit has been given for contributions). |
| </li> |
| <li>Tag the release in CVS |
| (tags for releases usually have the form Xerces-J_x_y_z |
| where x.y.z is the Xerces-J release number) |
| You should also tag the current branch of xml-commons |
| containing the API's that the parser needs to conform |
| to; see step 1 above. |
| </li> |
| <li>Do a test build and regression test run; |
| i.e., <code>build test</code> at a bare minimum. |
| In general, apply as many test suites (Oasis XML |
| tests, W3C DOM and Schema tests etc.) as are |
| available, particularly with a view to preventing |
| regressions since the previous release. |
| </li> |
| <li>Do the final build based on that tag:<br/> |
| windows build to produce <code>.zip</code> |
| packages<br/> |
| unix build (on a unix machine to make sure no 0x0d's |
| appear in documentation of <code>.tar.gz</code> |
| packages. Beware to do the build from within |
| X-windows to avoid problems with StyleBook on the |
| command-line! |
| </li> |
| <li>zip and tar the tools directory</li> |
| <li> |
| Generate PGP/GNUPG signatures for dist binaries:<br/> |
| That is, add public key to the CVS <code>KEYS</code> file if necessary |
| and make sure public key is on a key server or two. |
| </li> |
| <li>Upload the binaries and signatures to the dist section of |
| the website</li> |
| <li>Update |
| <code>/www/xml.apache.org/dist/xerces-j/.htaccess</code>, |
| which directs the user to the most recent release. Take |
| care to move old packages to the <code>old_xerces</code> |
| directory so that the package listing is manageable. |
| </li> |
| <li>Prepare release e-mail -- be sure to give contributors |
| credit for their work</li> |
| <li>Send the release e-mail to the xerces-j lists, general@xml and, if |
| it's a big enough release, announcements@xml.apache.org and |
| announcements@apache.org |
| </li> |
| <li>Bugzilla :<br/> |
| Firstly, create new release. Then, |
| remove oldest release (if we are up-to 6 |
| releases). |
| </li> |
| <li>Website:<br/> |
| Upload generated docs directory to daedalus (until this process |
| matures and becomes CVS-based). |
| Commit <code>/www/xml.apache.org/xerces2-j</code> to CVS; |
| i.e., update the xml-site module. |
| </li> |
| </ol> |
| </a> |
| </faq> |
| </faqs> |
| |
