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 "DerbySnapshotOrRelease" by JohnHEmbretsen
Date Wed, 21 Nov 2007 16:33:52 GMT
Dear Wiki user,

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

The following page has been changed by JohnHEmbretsen:
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease

The comment on the change is:
Added section: Making a (private) Quick Build of Release Artifacts

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

  
- 2. You don't have to polish the release notes for snapshots.
+  1. You don't have to polish the release notes for snapshots.
  
- 3. 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. 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.
+ 
- 4. Snapshots are placed in a different location:
+  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 '''''only 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 are suitable for reviewing the file structure of
a release, among other things, do the following steps (extraced 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.txt
BUILDING.txt]
+ 
+  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
+ 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. In the top-level directory of the source code tree, do:
+    {{{
+ # If you have built release artifacts or snapshots before, clean up. Also
+ # clean up 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
+ 
+ # In any case do this:
+ ant clobber
+ ant sane ; ant all ; ant buildjars   # for lib-debug
+ ant clobber
+ ant insane
+ ant -Dsane=false snapshot
+ cd tools/release
+ ant release
+    }}}
+ 
+ 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