This page documents the process of creating a FOP release.
FOP releases are coordinated by one member of the team (currently Christian Geisert), so others do not ordinarily need to use this information.
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 was assembled from Christian Geisert's notes. It will be expanded in the future as he has time.
- Determine whether this is a Release Candidate or a Release.
- Determine whether further testing is required.
- Edit release notes, and commit any changes.
- Update version number in build.xml, and commit the change.
- Tag the source tree with the release ID. For example, if the release is 0.20.5rc3:
cvs tag fop-0_20_5rc3
- Make a fresh checkout with the just created tag:
cvs -d :pserver:firstname.lastname@example.org:/home/cvspublic co -r
- Copy jimi and jai to lib/ (jimi-1.0.jar, jai_core.jar, jai_codec.jar)
- Copy jce-jdk13-119.jar from
from http://www.bouncycastle.org/latest_releases.html to lib/
- Run build[.sh] dist. Use jdk1.3. A Forrest installation is needed.
- Create signatures. Don't forget to upload your KEY:
gpg -a -b --force-v3-sigs fop-0.20.5rc3-bin.tar.gz etc.
- Upload to www.apache.org. (An account on daedalus is needed):
- Check permissions:
chmod 664 ... ; chgrp xml ...
- Add MD5 sums: md5 fop-0.20.5rc3-bin.tar.gz >
- Make a test download.
- Wait 24 hours (for the mirrors to catch up).
- Post announcements on fop-dev and fop-user mailing lists.
- Add bugzilla entry for the new release id.
The following is a sample of some other project release checlists, which might be consulted for ideas:
Following are links with information about mirroring: