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 RichardHillegas
Date Tue, 12 Oct 2010 17:35:03 GMT
Dear Wiki user,

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

The "DerbySnapshotOrRelease" page has been changed by RichardHillegas.
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease?action=diff&rev1=160&rev2=161

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

  You're done!
  
  
- = Snapshots =
+ = Snapshots and Quick Builds =
  
+ See SnapshotsAndQuickBuilds
- 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.
- 
  
  = Deprecated instructions =
  

Mime
View raw message