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 MyrnavanLunteren
Date Tue, 26 Jun 2007 18:47:23 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/DerbySnapshotOrRelease

------------------------------------------------------------------------------
  
   1. Drive the bug list to zero.
  
-   As the list of remaining bugs in JIRA approaches zero, be sure to mark their status properly
in JIRA. Mark blocker and critical bugs as such so that others can see the status at a glance.
Move non-showstopper bugs out to future releases if it appears they will not be fixed for
this release. 
+   As the list of remaining bugs in JIRA approaches zero, be sure to mark their status properly
in JIRA. Mark blocker and critical bugs as such so that others can see the status at a glance.
Move non-showstopper bugs out to future releases if it appears they will not be fixed for
this release.
  
   1. Drive the creation of release notes.
    The release note generator expects files called 'ReleaseNote.html' for each item marked
that is:
@@ -95, +95 @@

   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.
  
  
-  1. Make sure your public PGP/GPG key is in the KEYS file 
+  1. Make sure your public PGP/GPG key is in the KEYS file
  
    For information about PGP and why it is used to sign release binaries at Apache, please
read [http://people.apache.org/~henkp/trust/].
  
    You should create a PGP key for yourself if you do not have one, and upload it to at least
one, preferably two, of the main public keyservers, e.g. pgp.mit.edu. You will need this key
to sign the release binaries. Ideally, your key should be tied into the Apache web of trust.
-  
+ 
    GPG is available for a variety of platforms from http://gnupg.org. PGP is a commercial
product which is available from http://pgp.com.
  
   1. For major releases, create a new branch for the release, in both the code and docs trees.
@@ -215, +215 @@

  signone $1-src.zip}}}
  
    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 md5 switch is "-n" rather than "-q".
-  
+ 
   1. Verify the signatures and checksums.
  
    As an example, the Derby 10.1 archives would be verified with PGP as follows:
@@ -255, +255 @@

  
    Make sure that the community addresses relevant items on the ReleaseVettingChecklist.
  
-  1. If vote does not pass and go back to 'Drive bug list to zero'.   
+  1. If vote does not pass and go back to 'Drive bug list to zero'.
  
    If the vote does not pass and additional release candidates need to be made, then presumably
it won't have passed because of a showstopper-type bug or similar issue. So, go back to the
bug-fixing section.
  
@@ -266, +266 @@

    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
/www/www.apache.org/dist/db/derby on people.apache.org. 
+   Copy the distribution archives and their signatures/checksums to a new directory underneath
/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 shell script for doing so: 
+   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.asc db-derby-current-bin.tar.gz.asc
  ln -s $1/$1-bin.tar.gz.md5 db-derby-current-bin.tar.gz.md5
@@ -299, +299 @@

    For instructions on how to build the website, see item 3 regarding snapshots above. 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. 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!
  
    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 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 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)
@@ -357, +358 @@

  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 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. 
+   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.
  
    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:
  
@@ -370, +371 @@

  
    Then do
  
-    $ maven clean 
+    $ maven clean
  
-    $ maven multiproject:deploy 
+    $ 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/.
@@ -382, +383 @@

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

Mime
View raw message