[EMAIL PROTECTED] wrote: > People who've been on this list a long time may recall a discussion Ted and > some of us had (about a year ago I think) where we tried to prepare a list > of steps to follow when preparing a release. With the growth in our pool > of committers, I thought it was (past) time to resurrect and update this
This is a great idea that we haven't followed through with. I'm all for it! I made a suggestion along similar lines sometime (I can't remember when now). I wanted to break the documentation into several sections: one for general Xerces users; one for advanced Xerces users -- those people wanting to take advantage of XNI; and one for Xerces contributors. The last would include documentation about how to submit patches (if they're not a committer) as well as docs on how to produce releases. > list; Once folks have had a look at it, I also propose that we put it in > CVS. Perhaps in our root directory, along with TODO and STATUS might work? > It'll be easier to keep up to date, as processes change and discoveries are > made by each new release manager. I don't like just relying on a series of simple text files like TODO, STATUS, etc. I would like it organized into a nice cohesive set of HTML docs. > Change the following files > build.xml The list of changes should be enumerated. > docs/releases.xml - be sure to give contributors credit for their work This file should be updated every time that a considerable bug fix or feature is committed into the repository. > 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 We should explain how to move the existing tag number up when last minute bug fixes have gone into the code base (the "cvs tag -f ..." command). > Do a test build and regression test run > i.e., build test at a bare minimum Which tests are you referring to? The limited regression tests that we have in CVS? or the XML conformance suite at OASIS using David Brownell's driver? > Do the final build based on that tag > windows build > unix build (on a unix machine to make sure no 0x0d's appear > zip and tar the tools directory > Generate PGP/GNUPG signatures for dist binaries > add public key to the KEYS file if necessary > make sure public key is on a key server or two > Upload the binaries and signatures to the dist section of the website > Update /www/xml.apache.org/dist/xerces-j/.htaccess, which directs the user > to the most recent release. > Prepare release e-mail -- be sure to give contributors credit for their work > Send the release e-mail to the xerces-j lists, general@xml and, if > it's a big enough release, [EMAIL PROTECTED] and > [EMAIL PROTECTED] > Bugzilla > [a] create new release > [b] remove oldest release (if we are up-to 6 releases) > Website > upload generated docs directory to daedalus (until this process > matures and becomes CVS-based) > Commit /www/xml.apache.org/xerces-j to CVS. > i.e., update the xml-site module Sounds like a good start. :) -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
