db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "SnapshotsAndQuickBuilds" by RichardHillegas
Date Tue, 12 Oct 2010 17:35:58 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The "SnapshotsAndQuickBuilds" page has been changed by RichardHillegas.
http://wiki.apache.org/db-derby/SnapshotsAndQuickBuilds

--------------------------------------------------

New page:
This is an appendix to the overall Derby release instructions found here: DerbySnapshotOrRelease

'''Table of Contents'''
<<TableOfContents(4)>>

= Snapshots =

In essence a snapshot differs from a full release (feature, or bug fix release) in the following
ways:

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


 1. You don't have to polish the release notes for snapshots.

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

 1. Snapshots don't necessarily include everything included in a full release, for example
demos, plugins etc.

 1. 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):

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

 1. Make sure you are able to build the code jars the regular way, as described in [[http://svn.apache.org/repos/asf/db/derby/code/trunk/BUILDING.html|BUILDING.html]]

 1. Check out (or update) the corresponding documentation tree, for example 
   https://svn.apache.org/repos/asf/db/derby/docs/trunk/ for trunk

 1. Build the documentation (all) as described on the [[http://db.apache.org/derby/manuals/dita.html|web
site]]

 1. 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 you doc build, for example:
   {{{
docs.out=/export/home/tmp/user/docTrunk/trunk/out
   }}}

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

 1. Ensure that 'sane=true' and 'debug=true' are not present in your ''ant.properties'', by
removing or commenting out those lines if present.

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

Mime
View raw message