This is an appendix to the overall Derby release instructions found here: DerbySnapshotOrRelease
Table of Contents
In essence a snapshot differs from a full release (feature, or bug fix release) in the following ways:
- A snapshot is an alpha or beta distribution cut from the trunk, while a release (candidate) is supposed to be a full-fledged, upgradeable distribution, and likely cut from a branch.
- You don't have to polish the release notes for snapshots.
- For snapshots, the vetting cycle is shorter and the community is willing to tolerate regressions and serious bugs in the interests of garnering early feedback.
- Snapshots don't necessarily include everything included in a full release, for example demos, plugins etc.
- Snapshots are placed in a different location:
- It's a good idea, once the snapshot has appeared on the site, to announce to derby-dev and derby-user that the new snapshot has been posted so interested testers can grab it.
Making a (private) Quick Build of Release Artifacts
Sometimes it is useful for a Derby developer to build a private version of the release artifacts (archives), for example to verify modifications made to the structure of a specific release distribution (-bin, -lib, -lib-debug, -src, etc.).
For example, when adding a new demo or changing which files gets included in certain subdirectories of a -bin distribution, reviewing generated release artifacts is often the only way to verify that modifications made to the build scripts are correct (of course, having a developer with knowledge of the build scripts and experience with the release building process review the patch thoroughly would help as well).
Note that this section describes only a small subset of the steps needed to build a real Apache Derby release. The generated artifacts are suitable for private testing purposes only.
- the development community has not been involved
- version numbers are probably incorrect
- release notes are wrong, or not included at all
- jars are not signed
- etc. etc.
To build a set of release artifacts that is suitable for reviewing the file structure of a release, among other things, do the following steps (extracted from the full release procedure description above):
- Check out (or update) the source tree from which you want to build release artifacts, for example
https://svn.apache.org/repos/asf/db/derby/code/trunk/ for the trunk
Make sure you are able to build the code jars the regular way, as described in BUILDING.html
- Check out (or update) the corresponding documentation tree, for example
Build the documentation (all) as described on the web site
Copy tools/ant/properties/packaging.tmpl to tools/ant/properties/packaging.properties and modify as necessary (see details above). The important thing here is to include a pointer to your doc build, for example:
Include the following in your ant.properties file (for 10.3 or newer), modified to suit your environment:
j14lib=/usr/local/java/jdk1.4/jre/lib # For 10.4 or newer: j15lib=/usr/local/java/jdk1.5/jre/lib # For JDBC 4 support jdk16=/usr/local/java/jdk1.6.0 # If you want Java ME-support: jsr169compile.classpath=/home/user/lib/cdc/jsr169.jar:/home/user/lib/cdc/btclasses.zip # May not be necessary (?): relnotes.src.reports=/home/user/derby/relnotes-reports # empty directory
Ensure that 'sane=true' and 'debug=true' are not present in your ant.properties, by removing or commenting out those lines if present.
- In the top-level directory of the source code tree, do:
ant prepareforrelease cd tools/release ant release
prepareforrelease will actually do:
# clean up classes, jars and javadoc: rm -rf jars javadoc snapshot # clean. rm -rf tools/release/crlf/ tools/release/lf/ # clean more. rm tools/release/maintversion.properties # really clean. rm tools/release/*.zip tools/release/*.tar.gz # really, rm tools/release/*.md5 tools/release/*.asc # really clean ant clobber ant sane ; ant all ; ant buildjars # for lib-debug ant clobber ant insane ant -Dsane=false snapshot
The release artifacts should now be available as .zip and .tar.gz files in the tools/release/ directory.
To clean up, run svn stat to see which files don't naturally belong in the repository.