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] Trivial Update of "DerbySnapshotOrRelease" by KristianWaagan
Date Tue, 16 Feb 2010 14:34:10 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 KristianWaagan.
The comment on this change is: Fixed verbatim tag, which have to have a line for itself it
seems..
http://wiki.apache.org/db-derby/DerbySnapshotOrRelease?action=diff&rev1=144&rev2=145

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

  
   1. <<Anchor(CutBranch)>>For major releases, create a new branch for the release,
in both the code and docs trees.
  
+   {{{
-   {{{svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/code/trunk/ https://svn.apache.org/repos/asf/db/derby/code/branches/{branchname}/
-m "Created the {branchname} source branch"
+ svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/code/trunk/ https://svn.apache.org/repos/asf/db/derby/code/branches/{branchname}/
-m "Created the {branchname} source branch"
- svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/docs/trunk/ https://svn.apache.org/repos/asf/db/derby/docs/branches/{branchname}/
-m "Created the {branchname} doc branch"}}}
+ svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/docs/trunk/ https://svn.apache.org/repos/asf/db/derby/docs/branches/{branchname}/
-m "Created the {branchname} doc branch"
+ }}}
  
   1. After creating the branch, bump the version number on '''trunk'''. There is not currently
an ant target for bumping the version number on the trunk so you need to edit `tools/ant/properties/release.properties`
on trunk by hand. Bump the major/minor properties as appropriate, zero out the maint property
(if it isn't zero already), and ensure the beta flag is set to true (if it isn't already).
E.g. after bumping from 10.4 to 10.5 `release.properties` should look similar to: 
+   {{{
-   {{{#Wed Jul 19 08:21:42 PDT 2006
+ #Wed Jul 19 08:21:42 PDT 2006
  drdamaint=0
  maint=0000000
  major=10
@@ -81, +84 @@

   1. Also consider bumping the version number for the upgrade tests on trunk at this time;
in method boot in java/engine/org/apache/derby/impl/sql/catalog/!DataDictionaryImpl.java,
modify the value for softwareVersion. But this can also be done the next time new upgrade
tests get added on trunk.
  
   1. <<Anchor(BranchVersion)>> On the '''new branch''', edit `tools/ant/properties/release.properties`
and update the value of the `maint` property. The exact value of depends on the type of release
(feature, update or snapshot). For a new feature release the value will typically be
+   {{{
-   {{{maint=1000000
+ maint=1000000
  }}}
    This will set the version string for the branch to 
+   {{{
-   {{{<major>.<minor>.1.0 (beta)
+ <major>.<minor>.1.0 (beta)
  }}}
    The relationship between the `maint` property and the version number reported by `sysinfo`
is given by the following equation: `maint=100000*3rd+4th`, (or `maint=1000000*fixpack+point`
as described in the [[http://db.apache.org/derby/papers/versionupgrade.html|Derby Versioning
Scheme]]. Note that a "fixpack" of 0 overrides the `beta` property in `tools/ant/properties/release.properties`
and tags the version string with "alpha"). See also the description of how to [[#ReleaseCandidate|spin
a release candidate]].  
  
@@ -177, +182 @@

  #sane=<sane should *not* be set>}}}
  
  For 10.4 and earlier, your `ant.properties` file also 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>}}}
  
@@ -302, +308 @@

  
   1. <<Anchor(CreateDistros)>>Create the distributions for release by running:
  
-   {{{svn up
+   {{{
+ svn up
  ant prepareforrelease
  cd tools/release
  ant release
  ant sign}}}
  
    (!) Note: ant prepareforrelease does  a few basic checks, and then:
+  {{{
-  {{{ant clobber
+ ant clobber
  rm -rf jars javadoc snapshot  # really clean
  rm tools/release/*.zip tools/release/*.tar.gz  # really,
  rm tools/release/*.md5 tools/release/*.asc     # really clean
@@ -341, +349 @@

  
    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_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}}}
@@ -350, +359 @@

  
    (!) In that case, you can also use this simple script to automate signing the release
archives:
  
+   {{{
-   {{{#!/bin/sh signone() {
+ #!/bin/sh signone() {
    gpg --detach-sign --armor $1
    md5 -q $1 > $1.md5
  }
@@ -372, +382 @@

  
    As an example, the Derby 10.1 archives would be verified with GPG as follows:
  
+   {{{
-   {{{gpg --verify derby_ui_plugin_1.1.0.zip.asc derby_ui_plugin_1.1.0.zip
+ gpg --verify derby_ui_plugin_1.1.0.zip.asc derby_ui_plugin_1.1.0.zip
  gpg --verify derby_core_plugin_10.1.1.zip.asc derby_core_plugin_10.1.1.zip
  gpg --verify db-derby-10.1.1.0-src.zip.asc db-derby-10.1.1.0-src.zip
  gpg --verify db-derby-10.1.1.0-src.tar.gz.asc db-derby-10.1.1.0-src.tar.gz
@@ -385, +396 @@

  
    The md5 checksums can be verified by generating them via another method. For example,
using openssl:
  
+   {{{
-   {{{openssl md5 < db-derby-10.1.1.0-src.zip
+ openssl md5 < db-derby-10.1.1.0-src.zip
  }}}
  
    And comparing the output of openssl to the output from ant in `db-derby-10.1.1.0-src.zip.md5`
@@ -395, +407 @@

  
   1. <<Anchor(Bump4th)>>Bump the fourth digit of the source in preparation for
a possible next build:
  
+   {{{
-   {{{cd tools/release
+ cd tools/release
  ant bumplastdigit}}}
  
    Commit the changed version number.
@@ -443, +456 @@

  
    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:
  
+   {{{
-   {{{ln -s $1/$1-bin.tar.gz db-derby-current-bin.tar.gz
+ 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
  ln -s $1/$1-bin.tar.gz.md5 db-derby-current-bin.tar.gz.md5
  ln -s $1/$1-bin.zip db-derby-current-bin.zip
@@ -458, +472 @@

  
    which, if you called the script linkcurrent.sh and put it in your home directory, could
be run as follows:
  
+   {{{
-   {{{cd /www/www.apache.org/dist/db/derby
+ cd /www/www.apache.org/dist/db/derby
  ~/linkcurrent.sh db-derby-10.1.1.0}}}
  
    using db-derby-10.1.1.0 as the release to link to -current as an example.
@@ -492, +507 @@

  
    (!) It is probably easier (especially if you have a high-latency connection to `people.apache.org`),
to create the x.y directory on the same machine where you built the release, but then you
need to upload the documention directory. A recursive copy using scp is going to take a long
time, so it is better to create an archive and copy that:
  
+   {{{
-   {{{ zip -r x.y.zip x.y
+ zip -r x.y.zip x.y
  scp x.y.zip you@people.apache.org:/www/db.apache.org/derby/docs/
  ssh you@people.apache.org
  cd /www/db.apache.org/derby/docs/
@@ -507, +523 @@

    a. Create an HTML file for the release. 
     (!) It is a good idea to use the previous release pages as templates, filling in the
changed details as necessary. 
  
+    {{{
-    {{{cd src/documentation/content/xdocs/releases
+ cd src/documentation/content/xdocs/releases
  cp release-x'.y'.z'.w'.html release-x.y.z.w.html
  vi release-x.y.z.w.html
  }}}
@@ -525, +542 @@

     * 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`, as described below, before building.
     * Make sure that the CGI script is made executable by setting `svn:executable` on it

  
+    {{{
-    {{{cd src/documentation/content/xdocs/releases 
+ cd src/documentation/content/xdocs/releases 
  cp release-x'.y'.z'.w'.cgi release-x.y.z.w.cgi
  svn add release-x.y.z.w.cgi      
  svn propset svn:executable ON release-x.y.z.w.cgi }}}
@@ -538, +556 @@

     
     (!) To see what the release page should look like, look at the release page for an even
older release.
  
+    {{{
-    {{{cd build/site/releases
+ cd build/site/releases
  svn delete release-x'.y'.z'.w'.cgi
  cd -
  cd src/documentation/content/xdocs/releases
@@ -567, +586 @@

  
     <!> Remember to svn add the new files and set `svn:executable` on the new CGI script
in `build/site/releases` after running forrest!
  
+    {{{
-    {{{rm -rf $FORREST_HOME/main/site/*  # Remove any files from a previous build
+ rm -rf $FORREST_HOME/main/site/*  # Remove any files from a previous build
  forrest site
  cp -r $FORREST_HOME/main/site build/site
  svn revert -R build/tmp build/site/skin
@@ -580, +600 @@

  
    a. Update the website on `people.apache.org`:
  
+    {{{
-    {{{ssh you@people.apache.org
+ ssh you@people.apache.org
  cd /www/db.apache.org/derby
  svn up}}}
  
@@ -612, +633 @@

  
     Your local diff should look something like:
  
+    {{{
-    {{{sanity=insane
+ sanity=insane
  -derby.jars=../../jars/${sanity}
  +derby.jars=/path/to/maven/jars
   
@@ -641, +663 @@

    a. Sign the individual jars. 
     Unfortunately, Maven renames the jars during deployment, so the jars now found in the
Maven repository have the version number embedded in the file name. E.g `derby.jar` has become
`derby-x.y.z.w.jar`. The name of the signature file needs to same as the name of jar with
the `asc` extension, but Maven apparently knows nothing about signatures, so we have to create
correctly named signatures by hand. The following script signs and renames the jars appropriately,
and should be run in the `${derby.jars}` directory. 
  
+    {{{
-    {{{for i in *.jar
+ for i in *.jar
  do
    gpg --armor --detach-sign $i   // enter your PGP passphrase for each iteration.
  done
@@ -653, +676 @@

  done}}}
  
    a. Upload the signatures to the jars directory:
+    {{{
-    {{{sftp {username}@people.apache.org
+ sftp {username}@people.apache.org
  cd /www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/jars/
  put *.jar.asc}}}
  
@@ -666, +690 @@

    {i} 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.
  
   1. {X} The maven deploy step expects to do scp without prompting for passwords. If you
can normally do scp, but get an error reflecting 'Failed to deploy', in org.apache.maven.wagon.providers.ssh.external.!ScpExternalWagon.put,
you may not have this set up. If this is the problem, one workaround is to do the copying
manually, as outlined in the next section. Or you can do the following steps (and ensure that
you append .ssh/authorized_keys, not overwrite):
+    {{{
-    {{{$ ssh-keygen -t dsa
+ $ ssh-keygen -t dsa
  --> press ENTER when prompted for a pass-phrase to get a null phrase.
  $ scp ~/.ssh/id_dsa.pub you@people.apache.org:
  >Password:...
@@ -677, +702 @@

   1. {X} Maven may not work for you especially on Windows. 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, sign them and then sftp the results to people.apache.org.

    a. To deploy the build artifacts to your local file system, set up project.properties
something like this:
  
+    {{{
-    {{{maven.repo.list=apache
+ maven.repo.list=apache
  maven.repo.apache=file:///home/myself/zdir
  maven.repo.apache.directory=garbage
  maven.repo.apache.username=garbage
@@ -703, +729 @@

    a. Use sftp to bulk put the artifacts into the corresponding subdirectories of `www/people.apache.org/repo/m1-ibiblio-rsync-repository/org.apache.derby/`.
Note that there are 3 directories of files (jars, poms, wars) which must be sftp'd from your
machine to the tree on people.apache.org.
  
   1. Update the release section in the Derby project DOAP file for an official release.
+   {{{
-   {{{ cd site-trunk
+ cd site-trunk
  vi doap_Derby.rdf
  svn commit}}}
  
@@ -723, +750 @@

  
   1. Tag the release in subversion.
  
+   {{{
-   {{{svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/code/branches/{version}/
https://svn.apache.org/repos/asf/db/derby/code/tags/{version}/
+ svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/code/branches/{version}/ https://svn.apache.org/repos/asf/db/derby/code/tags/{version}/
  svn copy -r {rev} https://svn.apache.org/repos/asf/db/derby/docs/branches/{version}/ https://svn.apache.org/repos/asf/db/derby/docs/tags/{version}/}}}
  
   1. Check in a copy of the jars to the jars directory of the repository.
@@ -807, +835 @@

  
   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:
+  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:
+  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:
@@ -825, +853 @@

  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. 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:
     {{{
@@ -834, +862 @@

  ant release
     }}}
  
- {{{prepareforrelease}}} will actually do:
+    ''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.
@@ -849, +877 @@

  ant -Dsane=false snapshot
  }}}
  
- The release artifacts should now be available as {{{.zip}}} and {{{.tar.gz}}} files in the
{{{tools/release/}}} directory.
+    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.
+    To clean up, run ''svn stat'' to see which files don't naturally belong in the repository.
  

Mime
View raw message