Apache™ FOP Development: Release Process
This page documents the process of creating a Apache™ FOP release. FOP releases are coordinated by some designated member of the team. The purpose of documenting it here is to facilitate consistency, ensure that the process is captured, and to allow others to comment on the process.
The checklist below is based on a combination of input from from Christian Geisert and Simon Pepping.
1. Define the new release
Determine which open bugs must be solved before a release can take place (release critical bugs). Make this bug depend on each release critical bug and write a short argument why the bug is release critical.
Determine whether this is a Release Candidate or a Release.
Determine whether further testing is required.
Commit any outstanding changes
2. Prepare the new release
Create a branch called
Edit release notes (
status.xmlin the root).
Check and update the copyright year in NOTICE and build.xml.
Update version number in
build.xml(not to be merged back into trunk).
Build the dist files (
build[.sh] dist) and upload them to your web directory on
fop-devML to check the branch and the generated dist files for errors.
Tag the source tree with the release ID. For example, if the release is 1.0:
svn copy https://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-1_0 https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0
Make a fresh checkout with the just created tag:
svn co https://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0
Copy the hyphenation patterns jar file
Alternatively, create a
build-local.propertiesfile that points to the above libraries.
build[.sh] dist. Do this using Sun JDK 1.5 or later. A Forrest installation is needed.
Create signatures. Don't forget to upload your KEY:
gpg -a -b --force-v3-sigs fop-1.0-src.tar.gzetc.
3. Publish the new release
Upload the dist and signature files to your web directory on people.apache.org (An account on minotaur is needed):
scp fop-1.0*.tar.gz* firstname.lastname@example.org:public_html/
chmod 664 ... ; chgrp xmlgraphics ...
Add MD5 sums:
md5 fop-1.0-src.tar.gz > fop-1.0-src.tar.gz.md5etc.
Make a test download.
4. Vote for the new release
Start a vote for the release on
email@example.com. The message should point to the release files and list the MD5 sums (
cat *.md5). The vote should remain open for 72hrs.
When the release is accepted, copy the release files, their md5 sum files and the signature files to
/www/www.apache.org/dist/xmlgraphics/fop/in the subdirectories
binaries. Create links to all files in the
fopdirectory. Remove the links to the files of the previous version.
Wait 24 hours (for the mirrors to catch up).
5. Update material
- Merge the changes of the subversion release branch back into trunk (not the version number in the build file) and delete the branch.
Ask an FOP Jira admin to
- rename trunk entry into the new release name,
- and create a new trunk entry
- create an issue at Jira-INFRA.
Copy trunk directory to a new release directory with the new version number.
Copy following files to the new release directory:
Update all markdown linkIds to the new release (elementids are of the form
[linkId]: fop_version/path_to_page_XXX"at the beginning of the files):
Update the following files to the new release
compliance.mdtext(version number in new release column)
In the new release directory, update the following files:
compiling.mdtext(change the introduction for trunk to that for a release).
Publish the updated documentation to the FOP website.
- Deploy the maven bundle.
6. Announce the new release
Post announcements on following suggested lists:
- firstname.lastname@example.org (from your apache.org address)
- email@example.com (subscriber-only)
- firstname.lastname@example.org (subscriber-only)
- email@example.com (subscriber-only)
- firstname.lastname@example.org (subscriber-only) (http://dita-ot.sourceforge.net/)
The following is a sample of some other project release checklists, which might be consulted for ideas:
Following are links with information about mirroring: