commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject cvs commit: jakarta-commons/xdocs/releases index.xml mirror.xml prepare.xml release.xml
Date Tue, 11 Mar 2003 22:52:30 GMT
rdonkin     2003/03/11 14:52:30

  Added:       xdocs/releases index.xml mirror.xml prepare.xml release.xml
  Log:
  First draft of new release guidelines
  
  Revision  Changes    Path
  1.1                  jakarta-commons/xdocs/releases/index.xml
  
  Index: index.xml
  ===================================================================
  <?xml version="1.0"?>
  
  <document>
  
   <properties>
    <title>First Time Mirroring</title>
    <author email="commons-dev@jakarta.apache.org">Commons Documentation Team</author>
   </properties>
  
   <body>
    <section name="Releasing Common Components">
      <subsection name='Introduction'>
          <p>
          The <em>Jakarta Commons</em> project differs from many other Jakarta
hosted subprojects because 
          it is comprised of multiple, independently released components. Therefore, the release
procedure
          for an individual component needs to be documented so that component authors follow
consistent
          practices.
          </p>
          <p>
          Individual components (such as Collections) might vary from these practices 
          but these steps should prove sufficient for the majority
          of cases. Any components which deviate substantially from this procedure should
document these 
          deviations.
          </p>
          <p>
          This document is the new, updated and revised release instructions. It describes
the 
          (slightly more involved) procedure for creating releases for the Apache mirroring
structure. 
          </p>
      </subsection>
      <subsection name='Documentation'>
          <p>
          <ul>
              <li><a href='prepare.html'>Preparations For A Release</a></li>
              <li><a href='mirror.html'>Mirroring For The First Time</a></li>
              <li><a href='release.html'>Cutting The Release - Step By Step</a></li>
          </ul>
          </p>
      </subsection>
    </section>
    <section name='Status'>
          <p>
          Status: <strong>Beta</strong>.
          </p>
          <p>
          Feedback - yes please! Post to the commons-dev mailing list.
          </p>
    </section>
   </body>
  </document>
  
  
  
  1.1                  jakarta-commons/xdocs/releases/mirror.xml
  
  Index: mirror.xml
  ===================================================================
  <?xml version="1.0"?>
  
  <document>
  
   <properties>
    <title>First Time Mirroring</title>
    <author email="commons-dev@jakarta.apache.org">Commons Documentation Team</author>
   </properties>
  
   <body>
    <section name="Mirroring For The First Time">
      <p>
      This document is intended to be read together with the main release instructions.
      It describes the additional steps that need to be taken when cutting a release
      for a component that will be mirrored for the first time.
      As usual, the <code>example text</code> consistently assumes that version
<em>1.2</em> 
      of component <em>foo</em> is being released.
      </p>
      <subsection name='0 Understanding How Mirroring Works'>
      <p>
      Read <a href='http://www.apache.org/dev/mirrors.html'>the Apache mirroring guidelines</a>

      and then<a href='http://cvs.apache.org/~bodewig/mirror.html'>Stefan Bodewig's
Step-By-Step Guide</a>.
      Also read and digest this document before starting.
      </p>
      </subsection>
      
      <subsection name='1 Create Directory Structure'>
      <p>
      The mirrored releases are stored on Daedalus (www.apache.org). The base directory is:
      </p>
      <source>
          /www/www.apache.org/dist/jakarta/commons/foo                      
      </source>
      <p>
      You need to create this directory and the following subdirectories:
      </p>
      <source>
        |--- source/
        |--- binaries/
           |--- platform/  [optional if produce platform-specific binaries]  
      </source>
      <p>
          Please double check that the permissions and ownership are correct. (Everyone should
be 
          able to change and read, the group (<em>jakarta</em>) should be able
to write as well.)
          Email pier (pier at apache dot org) now about the change so that he can ensure that
          the new directories are properly rsyns'd.
      </p>
      </subsection>
      
      <subsection name='2 Add Releases To Mirrored Directories'>
          <p>
          Follow the standard <a href='release.html'>release process</a> (sections
0-13) to create the distributions
          and upload into the newly created directories. 
          </p>
      </subsection>
      
      <subsection name='3 Add Component Entries To Jakarta Downloads'>
          <p>
          Add entries for component <em>foo</em> to the jakarta download pages.
          </p>
          <p>
          Edit <code>jakarta-site2/xdocs/site/binindex.xml</code>. Add a new entry
for the component
          in the mirrored and main site sections. Please make make sure that your component

          fits in with the alphabetic ordering.
          </p>
  <source>
      ...
      &lt;h3&gt;Using a mirror&lt;/h3&gt;
      ...
      &lt;ul&gt;
      ...
  --&gt; &lt;li&gt;&lt;a href="[preferred]/jakarta/commons/foo/binaries/"&gt;Commons
Foo 1.2&lt;/a&gt;&lt;/li&gt;
      ...
      &lt;/ul&gt;
      ...
      &lt;a name="main"&gt;&lt;h3&gt;Main distribution site&lt;/h3&gt;&lt;/a&gt;
      ...
      &lt;ul&gt; 
      ...
  --&gt; &lt;li&gt;&lt;a href="http://www.apache.org/dist/jakarta/commons/foo/binaries/"&gt;Commons
Foo 1.2&lt;/a&gt;&lt;/li&gt;
      ...
      &lt;/ul&gt;
      ...
  </source>
  
          <p>
          Edit <code>jakarta-site2/xdocs/site/sourceindex.xml</code>. Add a new
entry for the component
          in the mirrored and main site sections. Please make make sure that your component

          fits in with the alphabetic ordering.
          </p>
  <source>
      ...
      &lt;h3&gt;Using a mirror&lt;/h3&gt;
      ...
      &lt;ul&gt;
      ...
  --&gt; &lt;li&gt;&lt;a href="[preferred]/jakarta/commons/foo/source/"&gt;Commons
Foo 1.2&lt;/a&gt;&lt;/li&gt; 
      ...
      &lt;/ul&gt;
      ...
      &lt;a name="main"&gt;&lt;h3&gt;Main distribution site&lt;/h3&gt;&lt;/a&gt;
      ...
      &lt;ul&gt;
      ...
  --&gt; &lt;li&gt;&lt;a href="http://www.apache.org/dist/jakarta/commons/foo/source/"&gt;Commons
Foo 1.2&lt;/a&gt;&lt;/li&gt;
      ...
      &lt;/ul&gt;
      ...
  </source>
          <p>
          Test your pages but don't forget that the mirror links won't work until the pages
are uploaded. 
          Commit and update the jakarta web site in the usual way.
          </p>
          <p>
          Now complete <a href='release.html#13 Update Jakarta Web Site'>
          standard release procedure section 13</a>.
          </p>
      </subsection>
      
      <subsection name='4 Update commons release directory'>
      <p>
      Log on to Daedalus (www.apache.org).
      </p>
      <pre>
  > cd /www/jakarta.apache.org/builds/jakarta-commons/release/commons-foo
      </pre>
      <p>
      If a <code>README.html</code> already exists, then edit it. Otherwise, create
a new one.
      This document should tell users that they should download newer releases from the mirrors.
      </p>
      </subsection>
      <subsection name=' 5 Wait Until The Mirrors Are Updated'>
      <p>
      Please wait until you component's directory appears on the mirrors before continuing
with the release and
      posting your announcements. It's also good practice to test the download once it's been
mirrored.
      </p>
      </subsection>
    </section>  
    <section name='Status'>
          <p>
          Status: <strong>Beta</strong>.
          </p>
          <p>
          Feedback - yes please! Post to the commons-dev mailing list.
          </p>
    </section>
   </body>
  </document>
  
  
  
  1.1                  jakarta-commons/xdocs/releases/prepare.xml
  
  Index: prepare.xml
  ===================================================================
  <?xml version="1.0"?>
  
  <document>
  
   <properties>
    <title>Preparations</title>
    <author email="commons-dev@jakarta.apache.org">Commons Documentation Team</author>
   </properties>
  
   <body>
    <section name='Introduction'>
      <p>
      This document assumes that a release manager has already been selected by a <code>VOTE</code>,
      a release plan approved and also that the major (usually coding) tasks in that plan
have been 
      completed. It describes some standard jobs which should be done (usually by the release
manager) 
      before the final release is ready to be cut. 
      </p>
      <p>
      The <code>example text</code> consistently assumes that preparation are
being made to release 
      version <em>1.2</em> of component <em>foo</em>.
      </p>
    </section>
    <section name="Preparations">
      <subsection name='Update The Jar Manifest'>
          <p>
          Each commons component release jar should contain a <code>MANIFEST.MF</code>
conforming to the 
          <a href='http://java.sun.com/products/jdk/1.2/docs/guide/jar/manifest.html'>Sun
Manifest Format</a>.
          In additional, commons components should adhere to the
          <a href='http://java.sun.com/products/jdk/1.2/docs/guide/versioning/spec/VersioningSpecification.html#PackageVersioning'>
          Sun Package Versioning Standards</a>
          </p>
          <p>
          The jar manifest file is found at <code>foo/src/conf/MANIFEST.MF</code>.
The contents of this file
          need to be checked and the version numbers updated. For example:
          </p>
  <pre>
  Extension-Name: org.apache.commons.foo
  Specification-Title: "Jakarta Commons Foo"
  Specification-Vendor: "Apache Software Foundation"
  Specification-Version: "1.2"
  Implementation-Title: "org.apache.commons.foo"
  Implementation-Vendor: "Apache Software Foundation"
  Implementation-Version: "1.3"
  </pre>
      </subsection>
      <subsection name='Bugzilla'>
          <p>
          Resolve all bugs!
          They can be resolved by:
          <ul>
            <li>fixing</li>
            <li>marking them as <code>INVALID</code> or <code>WONTFIX</code></li>
            <li>marking them as <code>LATER</code> (indicating that they
will be resolved after this release)</li>
          </ul>
          </p>
      </subsection>
      <subsection name='Release Notes'>
          <p>
          Different components have their own ways of creating release notes. 
          Here's the hard way!
          </p>
          <p>
          Go through the CVS logs for all source files which have changed since the last version.
          Analyse the log messages. Enhancements and new features need to be collated by topic.
          Bugs fixed should be listed separately together with a short summary of the bug.
          </p>
      </subsection>
      <subsection name='Test Against Listed Dependencies'>    
          <p>
          Re-compile and re-run unit tests with the dependencies versions listed in the 
          component's <code>STATUS.html</code>. If necessary, update the version
numbers of these 
          dependencies or roll back the offending changes. The right way to resolve each of
these 
          dependency issues should probably be raised on the commons-dev list.
          </p>
      </subsection>
      <subsection name='Check LICENSE'>
          <p>
          Make sure that there is a <strong>complete</strong> 
          Apache Software License at the top of each source file. The so-called <em>short
form</em>
          of the license has not been approved and should not be used.
          </p>	
          <p>
          Also check that the years in the copyright statement in the license in each source
file and
          in the component <code>LICENSE.txt</code> have been updated appropriately.

          </p>
      </subsection>
    </section>
    <section name='Voting On Release'>
      <subsection name='Release Candidate'>
          <p>
          Once all the preparations agreed in the release plan has been completed, it's good
practice
          to create a Release Candidate. 
          </p>
          <p>
          Modify the build version number to indicate that this build is a release candidate.
For example, 
          the <code>commons-foo-1.2RC1</code>. Clean build, run the unit tests
and check that the javadocs 
          have the correct version number.
          </p>
          <p>
          Now tag (for example <code>FOO_1_2_RC1</code>) and build distributions
from that tag 
          (as per full release). For commons components, it's usually unnecessary to post
the 
          release candidate on the main release site. (It's usually good enough to upload
it 
          into the public folder <em>~/public_html</em> in your home directory

          on <code>cvs.apache.org</code>.)
          </p>
      </subsection>
      <subsection name='[VOTE] Release foo 1.0'>
          <p>
          Once the release candidate has been created and uploaded, now it's time to propose
the release VOTE.
          </p>
          <p>
          Post a <code>[VOTE] Release foo 1.0</code> email to <strong>commmons-dev@jakarta.apache.org</strong>
          and cc <strong>pmc@jakarta.apache.org</strong>. This should contain
a link to the release candidate.
          </p>
          <p>
          As per the Commons Project charter, votes of committers
          on the particular package in question (as listed in the <code>STATUS.html</code>)
are binding.
          If the <code>[VOTE]</code> is successful then continue. It is considered
good practice to allow
          enough time for people to express their opinions.
          </p>
      </subsection>
      <subsection name='Final Preparations'>
          <p>
          Once the vote has succeeded, then post a <code>[RESULT][VOTE] Release foo
1.0</code> email to 
          <strong>commmons-dev@jakarta.apache.org</strong> and cc <strong>pmc@jakarta.apache.org</strong>.
          </p>
          <p>
          Tag the release now. (This will ensure that there are no problems with badly timed
commits.)
          Please tag <strong>only</strong> the files in the subdirectory for this
component.
          Make check that all the files you have modified have been checked into CVS before
tagging 
          the release.
          </p>
          <pre>
  $ cd $JAKARTA_COMMONS_HOME/foo
  $ cvs tag FOO_1_2
          </pre>
      </subsection>
    </section>
    
    <section name='Status'>
          <p>
          Status: <strong>Beta</strong>.
          </p>
          <p>
          Feedback - yes please! Post to the commons-dev mailing list.
          </p>
    </section>
   </body>
  </document>
  
  
  
  1.1                  jakarta-commons/xdocs/releases/release.xml
  
  Index: release.xml
  ===================================================================
  <?xml version="1.0"?>
  
  <document>
  
   <properties>
    <title>Cutting The Release</title>
    <author email="commons-dev@jakarta.apache.org">Commons Documentation Team</author>
   </properties>
  
   <body> 
  <section name='Cutting The Release - Step By Step'>
      <p>
      This document gives step-by-step instructions for cutting a release. These instructions
      assume that the component uses an <code>Ant</code> based master build. If
the component 
      being released uses a <code>Maven</code> based master build then you'll
need to improvise a little!
      Any patches for <code>Maven</code> based master builds will be gratefully
received.
      </p>
      <p>
      This documentation is also pretty *nix-centric. Hopefully, release managers using windoz
will
      be able to work out what they need to do for their platform. Again, any patches for
windoz-based
      releases will be gratefully received.
      </p>
    <subsection name="0 Introduction">
      <p>
      Throughout this document, the <code>example text</code> consistently assumes
that version <em>1.2</em> 
      of component <em>foo</em> is being released by release manager <em>rdonkin</em>.
      </p>
      <p>
      The starting point for this document is that all the preparations for the release have
been completed,
      a release candidate created and a release <code>[VOTE]</code> successfully
passed. 
      Guidelines for these preparations can be found <a href='prepare.html'>here</a>.
      </p>
      <p>
      In particular, the build version for the component must have been updated to the release
number. 
      This is found in <code>build.xml</code>. The component should also be tested
and the documentation
      reviewed.
      </p>
    </subsection>
    
    <subsection name="1 Prepare Local Working Directory">
      <p>
      Prepare a local working directory to do all the zipping, signing and so on. 
      The <code>examples</code> assume this directory is called <code>release/foo</code>.
      </p>
    </subsection>
    
      <subsection name='2 Update CVS to Release Tag'>
      <p>
      The release code should already have been tagged. Update the CVS checkout 
      (from which the release will be cut) to this tagged version. 
      </p>
      <pre>
  $ cd jakarta-commons/foo/
  $ cvs -q up -A
  $ cvs -q up -r FOO_1_2
      </pre>
      <p>
      Check the build number (to make sure that the update worked correctly).
      </p>
      </subsection>
  
      <subsection name="3 Build Binary Distribution">
      <p>
      Clean build the binary distribution in the standard way. 
      </p>
      <pre>
  $ ant clean
  $ ant dist
      </pre>
      <p>
  Review the generated documentation and in particular ensure that the version number is correct.
Check <code>dist/RELEASE-NOTES.txt</code>.
      </p>
      </subsection>
      
      <subsection name='4 Create Binary Releases'>
      <p>
  Move the binary distributions (created above) to the local working directory 
  and then create compressed binary releases:
      <pre>
  $ mv dist ~/jakarta/release/foo/commons-foo-1.2
  $ cd ~/jakarta/release/foo
  $ tar zcvf commons-foo-1.2.tar.gz commons-foo-1.2
  $ zip -r commons-foo-1.2.zip commons-foo-1.2
      </pre>
      </p>
      </subsection>
      
      <subsection name='5 Create Source Distributions'>
      <p>
      <ol>
      <li>
  Create a temporary working directory:
  <pre>
  $ mkdir temp
  $ cd temp
  </pre>
      </li>
      <li>
  Export the tagged release:
  <pre>
  $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
  Logging in to :pserver:anoncvs@cvs.apache.org:/home/cvspublic
  CVS password: (anoncvs)
  
  $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic export -r FOO_1_2 jakarta-commons

  </pre>
      </li>
      <li>
      Move exported source to working directory:
  <pre>
  $ mv jakarta-commons/foo ../commons-foo-1.2-src
  $ cd ..
  $ rm -rf temp 
  </pre>
      </li>
      <li>
      Create tar.gz and zipped source releases:
  <pre>   
  $ tar zcvf commons-foo-1.2-src.tar.gz commons-foo-1.2-src
  $ zip -r commons-foo-1.2-src.zip commons-foo-1.2-src
  </pre>
      </li>
      </ol>
      </p>
  </subsection>
  <subsection name='6 Create Sums'>
  <p>
  MD5 is the standard hash algorithm used by Apache to allow users to verify the integrity
of releases. 
  There are various applications which can be used to create md5 checksums. 
  </p>
  <p>
  For example md5sum (on Linux):
  </p>
  <pre>
  $ md5sum commons-foo-1.2-src.tar.gz > commons-foo-1.2-src.tar.gz.md5
  </pre>
  <p>
  Then edit to remove the file name (change
  <code>a76169177e7a9b58118bcd993aff4a5e commons-foo-1.2-src.tar.gz</code>
  to <code>a76169177e7a9b58118bcd993aff4a5e</code>).
  </p>
  <p>
  Create md5 sums for the binary and source releases, both tarred and zipped versions. 
  These should be stored in files whose names are formed by suffixing the original <code>.md5</code>.
  So, you should end up with the following files:
  </p>
  <pre>
  commons-foo-1.2-src.tar.gz.md5
  commons-foo-1.2-src.zip.md5
  commons-foo-1.2.tar.gz.md5
  commons-foo-1.2.zip.md5
  </pre>
  </subsection>
  
  
  <subsection name='7 Sign Releases'>
      <p>
  OpenPGP (RFC2440) compatible detached signatures needed to be created for all releases.
  Various applications can be used to create these signatures. For example,
  <a href='http://www.gnupg.org'>Gnu Privacy Guard</a> on linux:
      </p>
  <pre>
  $ gpg --output commons-foo-1.2-src.tar.gz.asc --detach-sig commons-foo-1.2-src.tar.gz  
 
  You need a passphrase to unlock the secret key for
  user: "Robert Burrell Donkin (CODE SIGNING KEY) &lt;rdonkin@apache.org&gt;"
  1024-bit DSA key, ID B1313DE2, created 2003-01-15
  </pre>
      <p>
  Signatures for all varieties of release need to be create. The signature files should be

  named after the original with <code>.asc</code> suffixed.
      </p>
  <pre>
  $ gpg --output commons-foo-1.2-src.tar.gz.asc --detach-sig commons-foo-1.2-src.tar.gz 
  $ gpg --output commons-foo-1.2-src.zip.asc --detach-sig commons-foo-1.2-src.zip
  $ gpg --output commons-foo-1.2.zip.asc --detach-sig commons-foo-1.2.zip
  $ gpg --output commons-foo-1.2.tar.gz.asc --detach-sig commons-foo-1.2.tar.gz
  </pre>
      <p>
  If this is the first release you've cut for this component, then the code signing public
key 
  must be added to the <a href='#Check KEYS file'><code>KEYS</code> file
for the component</a>.
      </p>
  </subsection>
  
  
  <subsection name='8 Test Releases'>
  <ul>
  <li>
  <strong>Verify signatures</strong>.
  Use another user to verify the signatures. (The user must have the code-signing public key
loaded
  into their key ring.) Here's an example using GnuPG:
  <pre>
  % gpg --verify commons-foo-1.2.tar.gz.asc commons-foo-1.2.tar.gz
  gpg: Signature made 03/01/03 19:34:31 GMT using DSA key ID B1313DE2
  gpg: Good signature from "Robert Burrell Donkin (CODE SIGNING KEY) &lt;rdonkin@apache.org&gt;"
  % gpg --verify commons-foo-1.2.zip.asc commons-foo-1.2.zip
  gpg: Signature made 03/01/03 19:34:05 GMT using DSA key ID B1313DE2
  gpg: Good signature from "Robert Burrell Donkin (CODE SIGNING KEY) &lt;rdonkin@apache.org&gt;"
  % gpg --verify commons-foo-1.2-src.zip.asc commons-foo-1.2-src.zip
  gpg: Signature made 03/01/03 19:33:42 GMT using DSA key ID B1313DE2
  gpg: Good signature from "Robert Burrell Donkin (CODE SIGNING KEY) &lt;rdonkin@apache.org&gt;"
  % gpg --verify commons-foo-1.2-src.tar.gz.asc commons-foo-1.2-src.tar.gz
  gpg: Signature made 03/01/03 19:32:56 GMT using DSA key ID B1313DE2
  gpg: Good signature from "Robert Burrell Donkin (CODE SIGNING KEY) &lt;rdonkin@apache.org&gt;"
      </pre>
  </li>
  <li>
  <strong>Check Sums</strong>.
  Verify md5 check sums. If you can, use another application to double check the sums. Here
  verifications are performed using openssl.
  <pre>
  % openssl md5 &lt;commons-foo-1.2-src.tar.gz
  a76169177e7a9b58118bcd993aff4a5e
  % cat commons-foo-1.2-src.tar.gz.md5
  a76169177e7a9b58118bcd993aff4a5e
  
  % openssl md5 &lt;commons-foo-1.2-src.zip
  ca0ae8330f666dd1626108346e36f799
  % cat commons-foo-1.2-src.zip.md5
  ca0ae8330f666dd1626108346e36f799
  
  % openssl md5 &lt;commons-foo-1.2.tar.gz
  460fa7ad1e9ee2b5c4acab4971402395
  % cat commons-foo-1.2.tar.gz.md5 
  460fa7ad1e9ee2b5c4acab4971402395
  
  % openssl md5 &lt;commons-foo-1.2.zip 
  d5f98c73f2450e09cc2b1af9509934f0
  % cat commons-foo-1.2.zip.md5
  d5f98c73f2450e09cc2b1af9509934f0
      </pre>
      </li>
  </ul>
  </subsection>
  
  
  <subsection name='9 Upload Releases'>
      <p>
  Upload the following to your home directory on daedalus:
      <ul>
          <li>all the release distributions</li>
          <li>the detached signature files (<code>.asc</code>) for these
releases</li>
          <li>the md5 sums (<code>.md5</code>) for these releases</li>
          <li>the release notes. (If you're using maven, you may need to create a stripped
down plain text
          version.</li>
      </ul>
      </p>
      <p>
  A tip is to tar and gz everything and upload it all together:
      </p>
  <pre>
  % scp release.tar.gz rdonkin@www.apache.org:~/
  release.tar.gz       100% |*********************************|   841 KB    00:46    
  % ssh -l rdonkin www.apache.org
  </pre>
  <p>
  Untar in a working directory. Remember to make sure that the group is <em>jakarta</em>,

  that they are world readable and that they are group read-writable.
  </p>
  <pre>
  &gt; chgrp jakarta release/*
  &gt; chmod g+w release/*
  &gt; chmod a+r release/*
  </pre>
  </subsection>
  
  <subsection name='10 Move Releases Into Mirrored Directories'>
      <p>
  Change directory to the main mirrored distribution directory for your component. 
  If this is missing, then this is the first mirrored release for this component. 
  Read <a href='mirror.html'>these guidelines</a> before continuing.
      </p>
  <pre>
  &gt; cd /www/www.apache.org/dist/jakarta/commons/foo/
  </pre>
      <p>
  Move source distributions, their detached signatures and md5 sums into position. 
  All source versions live in the source subdirectory.
      </p>
  <pre>
  &gt; mv ~/release/commons-foo-1.2-src* source
  </pre>
  <p>
  Move the binary distributions, their detached signatures and md5 sums into position. 
  All binary versions live in the <em>binaries</em> subdirectory.
  </p>
  <pre>
  &gt; mv ~/release/commons-foo-1.2* binaries
  </pre>
  <p>
  Double check the permissions for binaries and source distributions.
  </p>
  </subsection>
  
  <subsection name='11 Update Release Directory'>
      <ul>
      <li>
      <strong>Update README.html</strong>
      The contents of the <code>README.html</code> are displayed at the bottom
of the html 
      showing the directory listing.
      This document should be updated to reflect the new release.
  <pre>
  > vi README.html 
  </pre>
  Update the latest release number. Please also read through and correct any mistakes you
find
  and fix other items (eg. urls) which need updating. If your component is missing a <code>README.html</code>

  then add a new one modeled on a copy in another component.
      </li>
      <li>
      <strong>Replace README.html</strong>
      Copy the revised <code>README.html</code> into the binary and source directories,
replacing any old versions.
  <pre>
  &gt; cp README.html source
  &gt; cp README.html binaries
  </pre>
      </li>
      <li>
      <a name='Check KEYS file'/>
      <strong>Check KEYS file</strong>
  Check the <code>KEYS</code> file located in the main release directory. This
should contain all the public keys 
  which have been used to sign the component's releases. Make sure that this file exists and
that it contains
  the public key you've used to sign these releases. (The <code>KEYS</code> file
should give instructions about
  how to do this.)
      <pre>
  &gt; less KEYS
      </pre>
      </li>
      <li>
      <strong>Update Sym Links</strong>
      <ol>
      <li>Remove symbolic links to current distributions
  <pre>
  &gt; rm commons-foo-current*
  </pre>
      </li>
      <li>recreate links to current distribution
  <pre>
  &gt; ln -s source/commons-foo-1.2-src.tar.gz commons-foo-current-src.tar.gz 
  &gt; ln -s source/commons-foo-1.2-src.tar.gz.asc commons-foo-current-src.tar.gz.asc
  &gt; ln -s source/commons-foo-1.2-src.tar.gz.md5 commons-foo-current-src.tar.gz.md5
  &gt; ln -s source/commons-foo-1.2-src.zip commons-foo-current-src.zip
  &gt; ln -s source/commons-foo-1.2-src.zip.asc commons-foo-current-src.zip.asc
  &gt; ln -s source/commons-foo-1.2-src.zip.md5 commons-foo-current-src.zip.md5
  &gt; ln -s binaries/commons-foo-1.2.tar.gz commons-foo-current.tar.gz
  &gt; ln -s binaries/commons-foo-1.2.tar.gz.md5  commons-foo-current.tar.gz.md5
  &gt; ln -s binaries/commons-foo-1.2.tar.gz.asc commons-foo-current.tar.gz.asc
  &gt; ln -s binaries/commons-foo-1.2.zip commons-foo-current.zip
  &gt; ln -s binaries/commons-foo-1.2.zip.md5 commons-foo-current.zip.md5
  &gt; ln -s binaries/commons-foo-1.2.zip.asc commons-foo-current.zip.asc
  </pre>	
      </li>
      <li>Please test that these links function correctly.</li>
      </ol>
      </li>
      <li>
      <strong>Update RELEASE-NOTES</strong>.
      Replace the current <code>RELEASE-NOTES.txt</code> with the new release
notes.
  <pre>
  &gt; mv ~/release/RELEASE-NOTES.txt .
  </pre>
  Check that they are the right ones:
  <pre>
  &gt; less RELEASE-NOTES.txt 
  </pre>
      </li>
      </ul>
  </subsection>
  
  
  <subsection name='12 Test Main Site Downloads'>
      <p>
      You should now be able to get the new release from the main apache web site 
      (<code>http://www.apache.org/dist/jakarta/commons/foo/</code>). 
      </p>
      <p>
      Check the main directory:
      <ol>
          <li>
  Examine the directory listing page. At the bottom should be found the information you
  entered into the <code>README.html</code>. Please check that this is correct.
          </li>
          <li>
          Check the <code>KEYS</code> file
          </li>
          <li>
          Check the <code>RELEASE-NOTES.txt</code>
          </li>
          <li>Download and verify the current distributions</li>
      </ol>
      </p>
      <p>Follow the links to the binaries and source directories. Check them in a similar
manner.
      </p>
  </subsection>
  
  
  <subsection name='13 Update Jakarta Web Site'>
      <p>
  Follow standard procedures to update the Jakarta web site (stored in CVS repository 
  <code>jakarta-site2</code>) to reflect the availability of the new release).

  Remember to <code>cvs up -d -P</code> before you edit.
      </p>
      <ul>
      <li>
  <strong>Update Jakarta Download Pages'</strong>
  Update the Jakarta binary (<code>jakarta-site2/xdocs/site/binindex.xml</code>)
and 
  source (jakarta-site2/<code>xdocs/site/sourceindex.xml</code>) download pages.
  If your component is already listed then you just need to correct the version number.
  If your component is not listed then you need to add links to your component. 
  (Instructions are given in <a href='mirror.html'>First Time Mirroring</a>.)
      </li>
      <li>
  <strong>Update News Page</strong>
  Add a standard news item announcing the release to the Jakarta news page
  (<code>jakarta-site2/xdocs/site/news.xml</code>). 
  This should be similar to the announcement you'll post later to email lists. 
  Please remember to include a description of your component. 
  Please also add a reminder about verifying signature.
      </li>
      <li>
  <strong>Update Welcome Page</strong>
  Add a link to the news item to Jakarta welcome page (<code>jakarta-site2/xdocs/index.xml</code>)
  in the 'Product News' section. You might like to trim older items off the bottom of this

  list. (Leave at least 5 items of news.)
      </li>
      <li>
  <strong>Generate Documentation And Update Live Web Site</strong>
  Generate documentation in the standard way. From the <code>jakarta-site2</code>
directory
  <pre>
  % ant
  </pre>
  Check the generated documents (<code>jakarta-site2/docs</code>) for spelling
mistakes 
  and also check that the links to the releases on the main site are working.
  Don't worry about links to the mirrors at this stage since they won't be working.
  Once everything looks good, commit the changes. If you have an account on daedalus, 
  log in and update the web site:
  <pre>
  % cvs -q ci -m "Update to reflect commons-foo 1.2 release"
  
  &gt; cd /www/jakarta.apache.org/
  &gt; cvs up index.html site
  </pre>
  Check the live site. (The mirrors may or may not be in synch just yet.)
  </li>
  </ul>
  </subsection>
  
  
  <subsection name='14 Update Commons Web Site'>
      <ul>
      <li>
      <strong>Update Links</strong>.
          Update the API Docs and Release notes links (whilst you're still logged in on daedalus)
  <pre>
  &gt; cd /www/jakarta.apache.org/commons/foo
  &gt; rm RELEASE-NOTES.txt
  &gt; rm api
  &gt; rm -rf commons-foo-1.1
  &gt; tar xvzf /www/www.apache.org/dist/jakarta/commons/foo/commons-foo-current.tar.gz
  &gt; ln -s commons-foo-1.2/RELEASE-NOTES.txt RELEASE-NOTES.txt
  &gt; ln -s commons-foo-1.2/docs/api api
  </pre>
      </li>
      <li>
      <strong>Update Shared Pages</strong>.
      (You can log off daedalus now.)
  Edit the commons components page (<code>jakarta-commons/xdocs/components.xml</code>)
to reflect the
  new release. Add the new release to the list under the component description. If the list
of releases
  for your component is getting long then please consider removing some of the older ones.
  Check, commit and then update the web site in the normal manner.
  <pre>
  &gt; cd /www/jakarta.apache.org/commons/
  &gt; cvs -q up 
  </pre>
      </li>
      <li>
      <strong>Update Component Pages</strong>
          Make sure that the component's web site is up to date.
      </li>
      <li>
      <strong>Check commons release directory</strong>
  Check the commons release directory for your component on Daedalus 
  (<code>www/jakarta.apache.org/builds/jakarta-commons/release/commons-foo/</code>).

  Make sure that it has a <code>README.html</code> telling users that new release
should be
  obtained through the mirrors.
  If this file does not exist, please create one.
  Instructions are given in <a href='mirror#4 Update commons release directory'>First
Time Mirroring</a>.
      </li>
      </ul>
  </subsection>
  
  
  <subsection name='15 Create Announcements'>
  <p>
  Announce the availability of the new release. 
  You can probably use the news item create earlier as a basis for the announcement body.
  </p>
  <p>
  Please remember to give a brief description of you component. Please also remember to remind
people 
  about verifying the signatures. The subject should be something like <code>[ANNOUNCEMENT]
Foo 1.2 Released</code>. 
  You might like to send this mail from your apache account. Please spell check the document!
  </p>
  <p>
  This should go to (at least) the following mailing lists:
  <ul>
  <li>announcements@jakarta.apache.org</li>
  <li>commons-dev@jakarta.apache.org</li>
  <li>commons-user@jakarta.apache.org</li>
  </ul>
  </p>
  </subsection>
  
  
  <subsection name='16 Post Release Update'>
  <p>
  That's it! The release is out there - but there is still some tidying up to be done.
  </p>
  <p>
  If the release was cut from your main working checkout, remember to reset those sticky tags
  (created for the release) using a <code>cvs up -A</code>.
  </p>
  <ul>
  <li>
  <strong>Update STATUS.html</strong>
  Check and update STATUS.html:
  <ul>
  <li>Update Release Info section</li>
  <li>Endure Dependencies is correct</li>
  <li>Ensure completed tasks are removed from todo list</li>
  </ul>
  </li>
  <li>
  <strong>Update Build Version Number</strong>
      Update build number found in <code>build.xml</code>. This should be updated
to a <code>dev</code>
      release.
      <pre>
  Change 1.2 to 1.3-dev
      </pre>
  </li>
  </ul>
  </subsection>
  
  
  <subsection name='17 Update bugzilla'>
  <p>
  Check in bugzilla for all bugs which have been marked <code>LATER</code> and
reopen them. 
  If you need some changes made to bugzilla (for example, a new version number adding) 
  please contact Martin van den Bemt (mvdb at apache.org).
  </p>
  <p>
  Now is also an idea time to have a go at fixing some of those bugs you marked as <code>LATER</code>.
  </p>
    </subsection>
  </section>
    
    <section name='Status'>
          <p>
          Status: <strong>Beta</strong>.
          </p>
          <p>
          Feedback - yes please! Post to the commons-dev mailing list.
          </p>
    </section>
   </body>
  </document>
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message