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 "TmpDerbySnapshotOrRelease" by MyrnavanLunteren
Date Fri, 27 Jul 2007 07:24:21 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 MyrnavanLunteren:
http://wiki.apache.org/db-derby/TmpDerbySnapshotOrRelease

------------------------------------------------------------------------------
  '''Table of Contents'''
  [[TableOfContents(3)]]
  
- 
- 
- Temporary wiki page to work on Restructuring the instructions - see DERBY-2575.
- 
- 
  == Releases ==
  
  
  === high level time line ===
  once before release:
-   - volunteer for release manager
+   * volunteer for release manager
-   - create wiki pages (main, buddytesting, platform testing, app testing) for release
+   * create wiki pages (main, buddytesting, platform testing, app testing) for release
-   - (optional:) create branch
+   * (optional:) create branch
-   - ensure you have all required tools and files
+   * ensure you have all required tools and files
-   - ensure your KEYS are in place, and signed
+   * ensure your KEYS are in place, and signed
-   - create packaging.properties based on packaging.tmpl
+   * create packaging.properties based on packaging.tmpl
-   - create buddytesting page and troll for buddies 
+   * create buddytesting page and troll for buddies 
- for each release candidate
+ for each release candidate:
-   - ensure all new files have correct copyright & license
+   * ensure all new files have correct copyright & license
-   - arrange for appropriate version numbers in JIRA
+   * arrange for appropriate version numbers in JIRA
-   - svn update source and doc trees
+   * svn update source and doc trees
-   - add new section to testing wiki pages
+   * add new section to testing wiki pages
-   - drive bug list to zero
+   * drive bug list to zero
-   - update release.properties
+   * update release.properties
-   - create maintversion.properties
+   * create maintversion.properties
-   - update masters (ant regex) and test
+   * update masters (ant regex) and test
-   - ensure all release notes are current
+   * ensure all release notes are current
-   - copy rrefexcept.dita from <source>/classes/doc to <docsource>/src/ref
+   * copy rrefexcept.dita from <source>/classes/doc to <docsource>/src/ref
-   - update releaseSummary.xml, create release notes & changes files
+   * update releaseSummary.xml, create release notes & changes files
-   - clean doc & source trees, build release artifacts
+   * clean doc & source trees, build release artifacts
-   - (optional:) build eclipse plugin
+   * (optional:) build eclipse plugin
-   - sign and place on people.apache.org web site
+   * sign and place on people.apache.org web site
-   - verify a downloaded lib, bin and src distribution (build in the src distribution, preferably
create a release). 
+   * verify a downloaded lib, bin and src distribution (build in the src distribution, preferably
create a release). 
-   - bump version 
+   * bump version 
-   - update release wiki page
+   * update release wiki page
-   - call for vote
+   * call for vote
- once after candidate passes vote
+ once after candidate passes vote:
-   - tally vote & announce
+   * tally vote & announce
-   - put files on mirrors
+   * put files on mirrors
-   - create web page for release
+   * create web page for release
-   - update STATUS file
+   * update STATUS file
-   - deploy to maven repository
+   * deploy to maven repository
  
  === communicate with the community ===
  
@@ -61, +56 @@

  
   1. Make a wiki page for the release. 
  
- On it, identify timeframes, and let the community identify items for special mention (or
do this yourself). Also prepare a place to gather testing information (for instance, use a
previous' release's wiki pages as a starting point).
+   On it, identify timeframes, and let the community identify items for special mention (or
do this yourself). Also prepare a place to gather testing information (for instance, use a
previous' release's wiki pages as a starting point).
  
   1. Arrange for appropriate version numbers in JIRA
  
- The JIRA administrators will need to do this. This is a little more tricky than it seems;
You have to decide what the release is going to be called, and it ties in with the technical
part of where the release info is coming from in the code (essentially, <branch/trunk>/tools/ant/properties/release.properties).
Note, if you need to make a branch, that the first release off the branch will report 'beta',
no matter what the 'beta' flag in release.properties says. A release candidate should not
have the 'beta' flag.
+   The JIRA administrators will need to do this. This is a little more tricky than it seems;
You have to decide what the release is going to be called, and it ties in with the technical
part of where the release info is coming from in the code (essentially, <branch/trunk>/tools/ant/properties/release.properties).
Note, if you need to make a branch, that the first release off the branch will report 'beta',
no matter what the 'beta' flag in release.properties says. A release candidate should not
have the 'beta' flag.
  
   1. Drive the bug list to zero
  
- Communicate with the community about which bugs need to get fixed, which bugs need release
notes, and what else needs to be in the release notes. 
+   Communicate with the community about which bugs need to get fixed, which bugs need release
notes, and what else needs to be in the release notes. 
  
   1. Address items on the ReleaseVettingChecklist
  
@@ -106, +101 @@

  
   1. Drive the creation of release notes.
    The release note generator expects files called 'ReleaseNote.html' for each item marked
that is:
-     - resolved to 'Fixed'
+     * resolved to 'Fixed'
-     - fixed in the release under study but not in the previous release
+     * fixed in the release under study but not in the previous release
-     - marked with 'Existing Application Impact' or 'Release Note Needed'.
+     * marked with 'Existing Application Impact' or 'Release Note Needed'.
  
  
  === prepare the source for building the release ===
@@ -137, +132 @@

  
    Your KEY needs to be in the KEYS file in trunk, KEYS file on the branch if you've created
one, and the KEYS file in /www/www.apache.org/dist/db/derby at people.apache.org.
  
+  1. Check that all creative works have ASF license headers. See: [http://wiki.apache.org/db-derby/FixingLicenseHeader].

-  1. Check that all creative works have ASF license headers. See: [http://wiki.apache.org/db-derby/FixingLicenseHeader].
Also ensure that the year in NOTICE is correct. Similarly, ensure that all versions and copyright
details in the docs tree are correct, this includes the top level conrefs.dita, as well as
lower level dita files.
+   Also ensure that the year in NOTICE is correct. Similarly, ensure that all versions and
copyright details in the docs tree are correct, this includes the top level conrefs.dita,
as well as lower level dita files.
  
  === prepare for the release management task ===
  
  To be able to produce the release artifacts, you need to
- - update version numbers and run tests to verify it was correct
+   * update version numbers and run tests to verify it was correct
- - generate release notes and changes.html
+   * generate release notes and changes.html
- - build all in doc and source objects (except for eclipse ui and doc plugins, those are
optional)
+   * build all in doc and source objects (except for eclipse ui and doc plugins, those are
optional)
- - sign 
+   * sign 
- - verify
+   * verify
- - modify derby web
+   * modify derby web
- - distribute to maven
+   * distribute to maven
  
  This means you have to have to be able to do the following / use the following tools:
- - md5 
+   * md5 
- - pgp (see: [http://people.apache.org/~henkp/trust/], [http://gnupg.org] or [http://pgp.com.]
)
+   * pgp (see: [http://people.apache.org/~henkp/trust/], [http://gnupg.org] or [http://pgp.com.]
)
- - ant (see BUILDING.txt)
+   * ant (see BUILDING.txt)
- - dita (see:  )
- - forrest (see:  )
+   * dita (see: [http://db.apache.org/derby/manuals/dita.html] )
+   * forrest (see: [http://db.apache.org/derby/papers/derby_web.html] )
- - eclipse (optional)
+   * eclipse (optional)
  
  And you have to have the following files available:
- - osgi.jar (see BUILDING.txt)
+   * osgi.jar (see BUILDING.txt)
- - j2me implementation (see BUILDING.txt)
+   * j2me implementation (see BUILDING.txt)
- - jdk16 implementaion (see BUILDING.txt)
+   * jdk16 implementaion (see BUILDING.txt)
- - junit.jar (see BUILDING.txt)
+   * junit.jar (see BUILDING.txt)
- - ditazip (see: )
+   * DITA-OT1.1.2.1_bin-ASL.zip (see: [http://db.apache.org/derby/manuals/dita.html])
  
  You need to at least have the doc tree and source tree available, and your ant.properties
file needs to include:
- j14lib=<location of jdk14(2)/jre/lib>
+ {{{j14lib=<location of jdk14(2)/jre/lib>
  jdk16=<location of jdk16>
  jsr169compile.classpath=<location of jsr169 implementation>
  junit=<location of junit.jar>
  build.compiler=<modern, or see BUILDING.txt for other options>
  proceed=true
  relnotes.src.reports=<location where you want to save/access the xml scripts for generating
release notes>
- #sane=<sane should *not* be set>
+ #sane=<sane should *not* be set>}}}
  
  
  special consideration for windows users:
- - ant sign, the last step in the ant release process, may not work.
+   * ant sign, the last step in the ant release process, may not work. 
-   try it out before the release time is there; if you cannot do this, you may achieve the
same using  the following script
+   try it out before the release time is there; if you cannot do this, you may achieve the
same using  the following script 
- 
- - similarly, you may use a script to verify the release
+   * similarly, you may use a script to verify the release
- 
- - your md5 tool may be different.
+   * your md5 tool may be different.
    you'll need to copy the file packaging.tmpl to packaging.properties and adjust it appropriately.
    
- 
- 
  === prepare your machine/environment for building the release artifacts ===
  
-  1. Bump the third version number, adjust the beta flag, finalize CHANGES, and RELEASE-NOTES
and check in the new 
+  1. Bump the third version number, adjust the beta flag, finalize CHANGES, and RELEASE-NOTES
and check in the new version and test masters. 
+   You will need to clobber and build to before you can see the changed release number(s)
reflected in the source. Note that the first release off a new branch is automatically beta,
even if you set the beta flag in tools/ant/properties/release.properties to false. Also adjust
version numbers in documentation by modifying the appropriate *conrefs.dita files.
+   There is not currently an ant target for bumping the third version number. The third and
fourth parts of the version are combined into a single property, maint, where maint = (third
digit * 1000000) + fourth digit. Also, if this is a major/minor (feature) release, you should
remove the beta flag at this time. You should update tools/ant/properties/release.properties
by hand and then run:
  
- version and test masters. You will need to clobber and build to before you can see the changed
release number(s) 
- 
- reflected in the source. Note that the first release off a new branch is automatically beta,
even if you set the 
- 
- beta flag in tools/ant/properties/release.properties to false. Also adjust version numbers
in documentation by 
- 
- modifying the appropriate *conrefs.dita files.
- 
-   There is not currently an ant target for bumping the third version number. The third and
fourth parts of the 
- 
- version are combined into a single property, maint, where maint = (third digit * 1000000)
+ fourth digit. Also, if 
- 
- this is a major/minor (feature) release, you should remove the beta flag at this time. You
should update 
- 
- tools/ant/properties/release.properties by hand and then run:
- 
-   {{{java org.apache.derbyBuild.maintversion2props tools/ant/properties/release.properties

+   {{{java org.apache.derbyBuild.maintversion2props tools/ant/properties/release.properties
tools/release/maintversion.properties
- 
- tools/release/maintversion.properties}}}
-   {{{cd tools/release
+ cd tools/release
  ant regex.masters}}}
  
    TODO: the regex.masters target does not currently account for changes in the beta flag.

  
-  1. Generate RELEASE_NOTES.html in the branch and check it into the svn repository.
+   1. Generate RELEASE_NOTES.html in the branch and check it into the svn repository.
  
    Please consult the instructions for [http://wiki.apache.org/db-derby/ReleaseNoteProcess
generating release notes].
  
   1. Sync the repository.
  
+   'svn up' in your subversion view to bring all files in your view up to the latest revision.
Otherwise, the version output by svn which is captured for the build number will be a range
(e.g. 290275:320938).
-   'svn up' in your subversion view to bring all files in your view up to the latest revision.
Otherwise, the version 
- 
- output by svn which is captured for the build number will be a range (e.g. 290275:320938).
- 
- 
  
   1. Check in the latest SQLState documentation.
  
+   The SQLStates are documented in the Reference Guide on the following page: rrefexcept71493.dita.
This file is generated by the Derby build and placed in classes/doc. Take the version of this
file generated by building the code branch and check it into the doc branch at src/ref/rrefexcept71493.dita.
-   The SQLStates are documented in the Reference Guide on the following page: rrefexcept71493.dita.
This file is 
- 
- generated by the Derby build and placed in classes/doc. Take the version of this file generated
by building the code 
- 
- branch and check it into the doc branch at src/ref/rrefexcept71493.dita.
  
   1. Make sure you have the doc tree checked out, and a clean copy of the source checkout.
  
@@ -248, +216 @@

  
   1. Build the documentation.
  
+   The documentation needs to be included in the -bin distribution and src, so you will need
to access the doc branch when running the ant release target. Information on building the
docs is located at [http://db.apache.org/derby/manuals/dita.html]. 
-   The documentation needs to be included in the -bin distribution and src, so you will need
to access the doc branch 
- 
- when running the ant release target. Information on building the docs is located at 
- 
- [http://db.apache.org/derby/manuals/dita.html]. 
  
   1. Copy packaging.tmpl to packaging.properties in tools/release and modify as necessary.
  
-   Once you have a copy of the documentation on your local machine, you will need to update
the property ${docs.out} 
+   Once you have a copy of the documentation on your local machine, you will need to update
the property ${docs.out} in tools/ant/properties/packaging.properties to point to your local
copy of the documentation. Check that the settings in tools/ant/properties/packaging.properties
are correct for your md5 hash tool and pgp/gpg tool and then go to the next step.
  
+   Most Unix distributions come with either md5 or md5sum. An md5sum utility for Windows
can be downloaded as a part of the !GnuWin32 port of the core Gnu utilities, from: http://gnuwin32.sourceforge.net/packages/coreutils.htm.
A standalone md5 utility can be found at http://www.fourmilab.ch/md5/. Note for the executable
available from this last location, the correct option for output is md5 -n.
- in tools/ant/properties/packaging.properties to point to your local copy of the documentation.
Check that the 
- 
- settings in tools/ant/properties/packaging.properties are correct for your md5 hash tool
and pgp/gpg tool and then 
- 
- go to the next step.
- 
-   Most Unix distributions come with either md5 or md5sum. An md5sum utility for Windows
can be downloaded as a part 
- 
- of the !GnuWin32 port of the core Gnu utilities, from: http://gnuwin32.sourceforge.net/packages/coreutils.htm.
A 
- 
- standalone md5 utility can be found at http://www.fourmilab.ch/md5/. Note for the executable
available from this 
- 
- last location, the correct option for output is md5 -n.
  
   1. Create the release distributions and checksums, sign the distributions
  
    Check your classpath for osgi.jar for OSGI support and make sure jsr169compile.classpath
is set for J2ME support. 
  
+   For 10.2 forward, make sure that you have JDK 1.6 available and that you've set the jdk16
property to the JAVA_HOME for your JDK 1.6 installation in your ant.properties so that the
JDBC 4.0 classes are built and the JDBC 4.0 javadoc is created. If you have the sane property
set in your ant.properties, remove it at this time to prevent it from overriding the false
setting passed into the snapshot target.
- For 10.2 forward, make sure that you have JDK 1.6 available and that you've set the jdk16
property to the JAVA_HOME 
- 
- for your JDK 1.6 installation in your ant.properties so that the JDBC 4.0 classes are built
and the JDBC 4.0 javadoc 
- 
- is created. If you have the sane property set in your ant.properties, remove it at this
time to prevent it from 
- 
- overriding the false setting passed into the snapshot target.
  
  === building the release artifacts ===
  
@@ -302, +248 @@

  ant release
  ant sign}}}
  
-     You will need to enter your PGP passphrase several times as the release distributions
are signed. This will 
+   You will need to enter your PGP passphrase several times as the release distributions
are signed. This will create the following files in your tools/release directory:
- 
- create the following files in your tools/release directory:
  
    *db-derby-[version]-bin.tar.gz
    *db-derby-[version]-bin.zip
@@ -315, +259 @@

    *db-derby-[version]-src.tar.gz
    *db-derby-[version]-src.zip
  
+   The Eclipse core plugin is generated in the snapshot directory at the top level by the
snapshot target. You should also create the Eclipse UI plugins (see plugins/eclipse/readme.txt,
except use the core plugin created in the snapshot), but this requires Eclipse. If you don't
want to do it yourself, those interested in the Eclipse plugins will likely volunteer to generate
them for you. You should also create checksums and signatures for these files with:
-   The Eclipse core plugin is generated in the snapshot directory at the top level by the
snapshot target. You should 
- 
- also create the Eclipse UI plugins (see plugins/eclipse/readme.txt, except use the core
plugin created in the 
- 
- snapshot), but this requires Eclipse. If you don't want to do it yourself, those interested
in the Eclipse plugins 
- 
- will likely volunteer to generate them for you. You should also create checksums and signatures
for these files 
- 
- with:
  
    {{{gpg --armor --detach-sign derby_ui_plugin_[version].zip
  gpg --armor --detach-sign derby_core_plugin_[version].zip
  md5 -q derby_ui_plugin_[version].zip > derby_ui_plugin_[version].zip.md5
  md5 -q derby_core_plugin_[version].zip > derby_core_plugin_[version].zip.md5}}}
  
-   There is a problem with the Ant 'sign' target on Cygwin that may occur elsewhere. If for
some reason the Ant 
+   There is a problem with the Ant 'sign' target on Cygwin that may occur elsewhere. If for
some reason the Ant 'sign' target hangs, it may be prompting and waiting for input that you
cannot see. In that case, you can also use this simple script to automate signing the release
archives:
  
+   {{{#!/bin/sh signone() {
- 'sign' target hangs, it may be prompting and waiting for input that you cannot see. In that
case, you can also use 
- 
- this simple script to automate signing the release archives:
- 
-   {{{#!/bin/sh
- 
- signone() {
    gpg --detach-sign --armor $1
    md5 -q $1 > $1.md5
  }
@@ -354, +284 @@

  
    Invoking this 'sign.sh db-derby-10.1.1.0' would sign all of the release archives for Derby
10.1.1.0, for example. 
  
- Be sure to replace the commands for gpg and md5 with the correct commands for your system.
Note that on cygwin, the 
+   Be sure to replace the commands for gpg and md5 with the correct commands for your system.
Note that on cygwin, the md5 switch is "-n" rather than "-q".
  
- md5 switch is "-n" rather than "-q".
- 
-  1. Verify the signatures and checksums.
+   1. Verify the signatures and checksums.
  
    As an example, the Derby 10.1 archives would be verified with PGP as follows:
  
@@ -385, +313 @@

  
   1. Post the distributions
  
-   Copy the files from tools/release to your public_html directory on people.apache.org.
Post to derby-dev so that 
+   Copy the files from tools/release to your public_html directory on people.apache.org.
Post to derby-dev so that  others can begin testing.
- 
- others can begin testing.
  
  
  === publish new release ===
@@ -399, +325 @@

    http://www.apache.org/dev/mirrors.html and
    http://www.apache.org/dev/mirror-step-by-step.html
  
-   Copy the distribution archives and their signatures/checksums to a new directory underneath

+   Copy the distribution archives and their signatures/checksums to a new directory underneath
/www/www.apache.org/dist/db/derby on people.apache.org.
  
- /www/www.apache.org/dist/db/derby on people.apache.org.
- 
-   If the new release is the most current release, link the -current links to the new files.
Here's a quick-and-dirty 
+   If the new release is the most current release, link the -current links to the new files.
Here's a quick-and-dirty shell script for doing so:
- 
- shell script for doing so:
  
    {{{ln -s $1/$1-bin.tar.gz db-derby-current-bin.tar.gz
  ln -s $1/$1-bin.tar.gz.asc db-derby-current-bin.tar.gz.asc
@@ -427, +349 @@

  
    using db-derby-10.1.1.0 as the release to link to -current as an example.
  
-   If this release supercedes a previous release on a branch, be sure to move the old files
to the archive. It is 
+   If this release supercedes a previous release on a branch, be sure to move the old files
to the archive. It is important that we keep our mirror directory tidy.
- 
- important that we keep our mirror directory tidy.
  
    You should also make sure that your public PGP key is in the KEYS file at /www/www.apache.org/dist/db/derby/KEYS
  
   1. Create a page for the release, build/update site
  
-   For instructions on how to build the website, see item 3 regarding snapshots below. It
is a good idea to use the 
+   For instructions on how to build the website, see item 3 regarding snapshots below. It
is a good idea to use the previous release pages as templates, filling in the changed details
as necessary. You should add a .cgi and a .html file for the release. The main thing to remember
is that the .cgi file should have the same name as the .html file. 
  
- previous release pages as templates, filling in the changed details as necessary. You should
add a .cgi and a .html 
- 
- file for the release. The main thing to remember is that the .cgi file should have the same
name as the .html file. 
- 
- Also, when you run 'svn up' on people.apache.org (3e above), make sure that the new .cgi
file is executable and 
+   Also, when you run 'svn up' on people.apache.org (3e above), make sure that the new .cgi
file is executable and otherwise has the correct permissions!
- 
- otherwise has the correct permissions!
  
    Note the following things when creating the release page:
-   * Be sure to specify that the src.tar.gz requires gnu tar to unravel (because of our usage
of ant tar to create 
+   * Be sure to specify that the src.tar.gz requires gnu tar to unravel (because of our usage
of ant tar to create this, using longfile=gnu for handling long filenames).
- 
- this, using longfile=gnu for handling long filenames).
-   * Forrest will not copy the release .cgi script over unless you make a link to it from
another page. Add the link 
+   * Forrest will not copy the release .cgi script over unless you make a link to it from
another page. Add the link to derby_downloads.html before building.
- 
- to derby_downloads.html before building.
    * Make sure that the .cgi script is made executable by setting svn:executable on it with
{{{svn propset 
+ svn:executable ON release-10.1.2.1.cgi}}}. Be sure to do this for both the precursor version
you created in src/documentation/content/xdocs/releases and for the generated copy which forrest
builds into build/site/releases.
+   * In order for the release HTML file to be pulled into the build, it is necessary to add
a line to the <uris> section of src/documentation/conf/cli.xconf. Near line 310 of that
file, add: <uri type="append" src="releases/release-10.1.2.1.html"/> (with the correct
version for your release)
- 
- svn:executable ON release-10.1.2.1.cgi}}}. Be sure to do this for both the precursor version
you created in 
- 
- src/documentation/content/xdocs/releases and for the generated copy which forrest builds
into build/site/releases.
-   * In order for the release HTML file to be pulled into the build, it is necessary to add
a line to the <uris> 
- 
- section of src/documentation/conf/cli.xconf. Near line 310 of that file, add: <uri type="append"

- 
- src="releases/release-10.1.2.1.html"/> (with the correct version for your release)
-   * Due to [http://issues.apache.org/jira/browse/FOR-480]FOR-480, the release page will
be built into your 
+   * Due to [http://issues.apache.org/jira/browse/FOR-480]FOR-480, the release page will
be built into your $FORREST_HOME/main/site directory.
+   * Due to [http://issues.apache.org/jira/browse/FOR-555]FOR-555, the HTML comments which
constitute the form template into which the mirrors.cgi script splices in the mirror information
will be removed by Forrest. It is necessary to add these comments back in to the release page
before committing or letting the site go live on people.apache.org.
+   * Subversion may report some files as changed which should be static. Revert anything
in build/site/skin or build/site/papers before committing your website changes ([http://db.apache.org/derby/papers/derby_web.html#odd_diffs
see the explanation]).
+   * Once you have committed your changes and updated the website on people, you can review
your changes by following the instructions at http://www.apache.org/dev/project-site.html
- 
- $FORREST_HOME/main/site directory.
-   * Due to [http://issues.apache.org/jira/browse/FOR-555]FOR-555, the HTML comments which
constitute the form 
- 
- template into which the mirrors.cgi script splices in the mirror information will be removed
by Forrest. It is 
- 
- necessary to add these comments back in to the release page before committing or letting
the site go live on 
- 
- people.apache.org.
-   * Subversion may report some files as changed which should be static. Revert anything
in build/site/skin or 
- 
- build/site/papers before committing your website changes 
- 
- ([http://db.apache.org/derby/papers/derby_web.html#odd_diffs see the explanation]).
-   * Once you have committed your changes and updated the website on people, you can preview
your changes by 
- 
- following the instructions at http://www.apache.org/dev/project-site.html
  
   1. Deploy to Maven repository.
  
-   First, if you do not already have the latest Maven 1 distribution, download it from http://maven.apache.org/maven
+   First, if you do not already have the latest Maven 1 distribution, download it from http://maven.apache.org/maven-1.x/start/download.html,
unpack it, and put the bin directory into your path so that you can run maven commands. As
of this writing, the latest 1.x version of Maven was 1.0.2.
  
+   Next, edit project.xml in the maven directory in the derby tree to contain the correct
version number for this release between the <currentversion> tags. Then, edit the project.properties
to contain the correct protocol, username, and password for your account on people.apache.org
so you can properly authenticate and copy the files to people. The scpexe protocol should
work without problems, especially if you have an ssh public key already on people. The project.properties
file in the maven directory should look something like this, for the maven.repo lines in the
file:
- -1.x/start/download.html, unpack it, and put the bin directory into your path so that you
can run maven commands. As 
- 
- of this writing, the latest 1.x version of Maven was 1.0.2.
- 
-   Next, edit project.xml in the maven directory in the derby tree to contain the correct
version number for this 
- 
- release between the <currentversion> tags. Then, edit the project.properties to contain
the correct protocol, 
- 
- username, and password for your account on people.apache.org so you can properly authenticate
and copy the files to 
- 
- people. The scpexe protocol should work without problems, especially if you have an ssh
public key already on 
- 
- people. The project.properties file in the maven directory should look something like this,
for the maven.repo lines 
- 
- in the file:
  
    {{{maven.repo.list=apache
  maven.repo.apache=scpexe://people.apache.org
@@ -508, +383 @@

  maven.repo.apache.password={your_password}
  maven.repo.apache.group=db}}}
  
-   Also, make sure you have the maven artifact plugin, version 1.5.2, so that maven generates
SHA1 checksums for the 
+   Also, make sure you have the maven artifact plugin, version 1.5.2, so that maven generates
SHA1 checksums for the files you upload, by running the following command:
- 
- files you upload, by running the following command:
  
    {{{maven plugin:download -DgroupId=maven \
    -DartifactId=maven-artifact-plugin \
    -Dversion=1.5.2}}}
  
-   NOTE: this should only be necessary for Maven 1.0.2. The latest artifact plugin will be
included in future stable 
+   NOTE: this should only be necessary for Maven 1.0.2. The latest artifact plugin will be
included in future stable releases of Maven 1.x.
- 
- releases of Maven 1.x.
  
    Then, cd into Derby's maven directory and
  
@@ -526, +397 @@

  
     $ maven clean   # will attain the multiproject:clean goal to clean up the maven tree
  
+    $ maven multiproject:deploy   # will copy all the artifacts into the apachecvs repository
(note, for now this has been disabled by commenting out the maven.repo.list definition in
project.properties).
-    $ maven multiproject:deploy   # will copy all the artifacts into the apachecvs repository
(note, for now this 
- 
- this has been disabled by commenting out the maven.repo.list definition in project.properties).
  
    This does not build using maven, it works by copying the jars that ant built into jars/${sanity}.
  
+   After successfully deploying the jars to the maven repository on minotaur, you may receive
an email that you did not upload appropriate PGP signatures for the new files added to www.apache.org/dist/.
To prevent receiving this mail, you will need to sign the individual jars and then upload
the signatures to /www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/jars
after running maven's multiproject:deploy target. The following script signs and renames the
jars appropriately, and should be run in the jars/insane directory.
-   After successfully deploying the jars to the maven repository on minotaur, you may receive
an email that you did 
- 
- not upload appropriate PGP signatures for the new files added to www.apache.org/dist/. To
prevent receiving this 
- 
- mail, you will need to sign the individual jars and then upload the signatures to /www/people.apache.org/repo/m1-
- 
- ibiblio-rsync-repository/org.apache.derby/jars after running maven's multiproject:deploy
target. The following 
- 
- script signs and renames the jars appropriately, and should be run in the jars/insane directory.
  
    {{{for i in *.jar
  do
@@ -559, +420 @@

  cd /www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/jars/
  put *.jar.asc}}}
  
-   The deployment of the jars and poms to the Maven 1 repository will be automatically converted
to appropriate jars 
+   The deployment of the jars and poms to the Maven 1 repository will be automatically converted
to appropriate jars and poms for Maven 2 and deployed to that repository as well. See [http://issues.apache.org/jira/browse/DERBY-1378
DERBY-1378] for more information on the automatic conversion to Maven 2.
  
- and poms for Maven 2 and deployed to that repository as well. See [http://issues.apache.org/jira/browse/DERBY-1378

+   Maven may not work for you. If Maven does not copy the build artifacts to subdirectories
under /www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/, then you
will have to do this yourself. 
  
+   In this scenario, you must use Maven to deploy the build artifacts to your local file
system and then sftp the results to people.apache.org. To deploy the build artifacts to your
local file system, set up project.properties something like this:
- DERBY-1378] for more information on the automatic conversion to Maven 2.
- 
-   Maven may not work for you. If Maven does not copy the build artifacts to subdirectories
under 
- 
- /www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/, then you will
have to do this yourself. 
- 
- In this scenario, you must use Maven to deploy the build artifacts to your local file system
and then sftp the 
- 
- results to people.apache.org. To deploy the build artifacts to your local file system, set
up project.properties 
- 
- something like this:
  
    {{{maven.repo.list=apache
  maven.repo.apache=file://~/zdir
@@ -589, +440 @@

     $ maven multiproject:deploy
  
  
+   This will build the artifacts into a subtree rooted at garbage. Use sftp to bulk put the
artifacts into the corresponding subdirectories of www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/.
-   This will build the artifacts into a subtree rooted at garbage. Use sftp to bulk put the
artifacts into the 
- 
- corresponding subdirectories of www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/.
  
  
   1. Update the Derby project DOAP file for an official release.
@@ -599, +448 @@

      Update the release section in this file:
      https://svn.apache.org/repos/asf/db/derby/site/trunk/doap_Derby.rdf
  
+    This DOAP file is the source for http://projects.apache.org/projects/derby.html . Projects
are supposed to get updated periodically (you don't do anything to publish the update). If
the update doesn't get generated within a day or two, send email to derby-dev@db.apache.org
letting them know you updated the file and that the update appears to be delayed (site-dev@apache.org
needs to be notified).
-    This DOAP file is the source for http://projects.apache.org/projects/derby.html . Projects
are supposed to get 
- 
- updated periodically (you don't do anything to publish the update). If the update doesn't
get generated within a day 
- 
- or two, send email to derby-dev@db.apache.org letting them know you updated the file and
that the update appears to 
- 
- be delayed (site-dev@apache.org needs to be notified).
  
  
   1. Announce the release.
  
+   Twenty-four hours after putting the release files in the mirror directory, verify that
you can reach them through a mirror. Then, you should email derby-dev, derby-user, general@db.apache.org,
announce@apache.org and anyone else you think might be interested an announcement concerning
the release. See past release announcements for examples.
-   Twenty-four hours after putting the release files in the mirror directory, verify that
you can reach them through 
- 
- a mirror. Then, you should email derby-dev, derby-user, general@db.apache.org, announce@apache.org
and anyone else 
- 
- you think might be interested an announcement concerning the release. See past release announcements
for examples.
  
    Include a description of the project, and a description of any significant new features
or important bug fixes. 
  
+   Every tech news blog remotely related to Java or databases will pick up the announcement
and post it verbatim, so it's a good idea to spell check it, proofread it a couple of times,
and/or get input from derby-dev on its content.
- Every tech news blog remotely related to Java or databases will pick up the announcement
and post it verbatim, so 
- 
- it's a good idea to spell check it, proofread it a couple of times, and/or get input from
derby-dev on its content.
  
   1. Tag the release in subversion.
  
@@ -638, +475 @@

  == Snapshots ==
   1. Update CHANGES.
  
+  Edit the CHANGES file to include a list of the bug fixes included in the snapshot. It is
not necessary to make an exhaustive list of subversion commits. Only changes that would be
visible to a user need to be included.
-  Edit the CHANGES file to include a list of the bug fixes included in the snapshot. It is
not necessary to make an 
- 
- exhaustive list of subversion commits. Only changes that would be visible to a user need
to be included.
  
   1.#2 Run the snapshot target.
  
@@ -654, +489 @@

  ant insane
  ant -Dsane=false snapshot}}}
  
-  It is best to do this in a view where there are no modified files or mixed revisions. This
will create a snapshot 
+  It is best to do this in a view where there are no modified files or mixed revisions. This
will create a snapshot directory at the top level, which will contain the five snapshot files:
- 
- directory at the top level, which will contain the five snapshot files:
  
    * db-derby-snapshot-[version]-[changenumber].tar.gz
    * db-derby-snapshot-[version]-[changenumber].zip
@@ -664, +497 @@

    * db-derby-snapshot-debug-[version]-[changenumber].zip
    * derby_core_plugin_[version]_[changenumber].zip
  
- The need to run 'ant insane' as a separate step before the snapshot is filed in JIRA as
DERBY-744.
+   The need to run 'ant insane' as a separate step before the snapshot is filed in JIRA as
DERBY-744.
  
   1.#3 Update the website.
  
-  For instructions on how to build the website using Forrest, please see:
+  For instructions on how to build the website using Forrest, please see: http://db.apache.org/derby/papers/derby_web.html
  
-  http://db.apache.org/derby/papers/derby_web.html
+   a. Place the five files created by the snapshot target into the src/documentation/content/xdocs/binaries
directory of the location to which you checked out the website source. 'svn add' them, and
'svn delete' any old snapshot that the new snapshot is replacing. Don't forget to 'svn add'
the files in the build part of the site tree.
  
-   a. Place the five files created by the snapshot target into the src/documentation/content/xdocs/binaries
directory 
- 
- of the location to which you checked out the website source. 'svn add' them, and 'svn delete'
any old snapshot that 
- 
- the new snapshot is replacing. Don't forget to 'svn add' the files in the build part of
the site tree.
- 
-  b. Update the derby_downloads.xml page in the src/documentation/content/xdocs directory
so that the links to the 
+  b. Update the derby_downloads.xml page in the src/documentation/content/xdocs directory
so that the links to the current snapshot point to your new files.
- 
- current snapshot point to your new files.
  
   c. Run 'forrest site' at the top of the site tree.
  
+  d. Check the changes. If they look good, 'svn commit' them. NOTE: you should revert any
changed files in build/tmp or build/site/skin. Also, please {{{svn delete}}} any old snapshot
files that are no longer necessary.
-  d. Check the changes. If they look good, 'svn commit' them. NOTE: you should revert any
changed files in build/tmp 
- 
- or build/site/skin. Also, please {{{svn delete}}} any old snapshot files that are no longer
necessary.
  
   e. Update the website on people.apache.org by logging into the machine and doing:
  
   {{{cd /www/db.apache.org/derby
  svn up}}}
  
-  Note that people.apache.org is rsync'd to the actual website every hour or so. Verify that
the changes appear on 
+  Note that people.apache.org is rsync'd to the actual website every hour or so. Verify that
the changes appear on the Derby website at http://db.apache.org/derby/derby_downloads.html
- 
- the Derby website at http://db.apache.org/derby/derby_downloads.html
  
   1.#4 Bump the version number.
  
@@ -704, +525 @@

   {{{cd tools/release
  ant bumplastdigit}}}
  
+  This target updates tools/ant/properties/release.properties and several test canons that
contain the version number. Check that the version number is correct. 'svn commit' the changed
files.
-  This target updates tools/ant/properties/release.properties and several test canons that
contain the version 
- 
- number. Check that the version number is correct. 'svn commit' the changed files.
  
   1.#5 Announce to the lists.
  
-  It's a good idea, once the snapshot has appeared on the site, to announce to derby-dev
and derby-user that the new 
+  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.
  
- snapshot has been posted so interested testers can grab it.
+  Also, a new JIRA version will need to be created for the new, bumped version number. An
email to derby-dev stating that you've bumped the version will (hopefully) be sufficient to
get the attention of one of the Derby JIRA admins to add a new version in JIRA.
  
-  Also, a new JIRA version will need to be created for the new, bumped version number. An
email to derby-dev stating 
- 
- that you've bumped the version will (hopefully) be sufficient to get the attention of one
of the Derby JIRA admins 
- 
- to add a new version in JIRA.
- 

Mime
View raw message