blob: 96cf8f82e0c696eec483b37f100e314bf5f580fa [file] [log] [blame]
The following steps are the rough guide to making a release. Please
update it if you find something inaccurate/missing.
This information is accurate as of the 3.1.2 release, which eliminated some
aspects of the release process (no binaries, elimination of the 2.8.0 web
site content).
Note that if a security issue is involved, you may need to edit content in
doc/secadv.xml and the doc/html/secadv/ directory as part of the release.
1. Update the version information in the following files (many only need changes
if the minor version increases, not just the patch version):
2. Update the release documentation in (at least) the following files:
3. Build and test the release on the platforms that the PMC indicates should be
considered "official". The four source packages should be named, and the distribution content
should be explicitly, and only, that produced by the make dist command.
4. Build the web site and API docs by running the following commands from within
the distribution (note that both Oracle's Java and doxygen must be installed):
$ cd tools
$ ./
$ cd ../doc
$ doxygen
You should be able to open the web site from doc/html/index.html and verify
the content.
5. Generate PGP/GNUPG signatures for all source distribution packages.
That is, add public key to the KEYS file in svn if necessary and make sure
public key is on a key server or two. You will also need to update the
KEYS file on the website, which is located in svn at:
6. Generate MD5, SHA1, and SHA256 hashes of the distribution files.
7. Check in the distributions, hashes, and signatures to the dist repository, in:
You should also remove the previous version from svn.
8. Verify that the downloads are available. Note that it can take up to
24 hours to for the mirrors to be updated.
9. Tag the release in SVN (tags for releases usually have the form
Xerces-C_x_y_z where x.y.z is the Xerces-C release number) by doing (e.g.,):
svn cp -m "Tagging the Xercesc x.y.z release" \ \
The exact command will depend on the release being done, and where the original
source is.
10. Close any resolved issues in Jira, and "release" the new version. Update the list
of future versions to ensure a patch version and a minor version are available to
assign issues against.
11. Update the website by copying the generated HTML in doc/html over the
checked in web site content located at:
You should either remove the original site content and commit that first,
or if you want to avoid the site being completely deleted online if there's
a problem, copy the content into a sandbox, then look for unchanged files
older than the time of the copy, and remove them from svn as part of the
site commit.
12. Send out an announcement e-mail to the and mailing lists.