release preparation template

[ne...@ca.ibm.com]

Hi folks,

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
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.

Anyway, here's the list so far:

Revised Proposed check list document for a Xerces-J Release

Change the following files
    build.xml
    docs/releases.xml - be sure to give contributors credit for their work
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
Do a test build and regression test run
    i.e., build test at a bare minimum
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, announcements@xml.apache.org and
    announcements@apache.org
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

Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone:  905-413-3519, T/L 969-3519
E-mail:  neilg@ca.ibm.com



---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org

Re: release preparation template

[Andy Clark <an...@apache.org>]

neilg@ca.ibm.com 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, announcements@xml.apache.org and
>     announcements@apache.org
> 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 * andyc@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org