cocoon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cziege...@apache.org
Subject cvs commit: cocoon-site/src/documentation/content/xdocs/devinfo releasing.xml
Date Tue, 08 Jun 2004 10:54:50 GMT
cziegeler    2004/06/08 03:54:50

  Modified:    src/documentation/content/xdocs/devinfo releasing.xml
  Log:
  Polishing
  
  Revision  Changes    Path
  1.2       +73 -48    cocoon-site/src/documentation/content/xdocs/devinfo/releasing.xml
  
  Index: releasing.xml
  ===================================================================
  RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/devinfo/releasing.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- releasing.xml	8 Jun 2004 08:20:43 -0000	1.1
  +++ releasing.xml	8 Jun 2004 10:54:50 -0000	1.2
  @@ -8,66 +8,78 @@
       <section>
         <title>Overview</title>
         <p>
  -        This info is for Cocoon committers who need to distribute a new release of Cocoon.
  +        This info is for Cocoon committers who need to distribute a new release of Cocoon
  +        or any subproject of Cocoon.
         </p>
       </section>
       <section>
  -      <title>A) Naming Conventions</title>
  +      <title>Naming Conventions</title>
         <p>
           The name of each downloadable archive should be named after the following
           regular expression:
         </p>
         <source>
  -        PROJECT(-SUBPROJECT)?-VERSION(-VARIANT)?-(src|bin).(zip|tar.gz) 
  +        cocoon(-SUBPROJECT)?-VERSION(-VARIANT)?-(src|bin).(zip|tar.gz) 
         </source>
         <p>
           Where:
         </p>
         <ul>
  -        <li>PROJECT is the name of the top-level project,</li>
           <li>SUBPROJECT is the name of the eventual subproject (optional)</li>
  -        <li>VERSION is a version string (without - dashes)</li>
  +        <li>VERSION is a version string without dashes (ex. 2.1.5, 2.2m1...)</li>
           <li>VARIANT identifies the "type of distribution" (ex. win32, jdk12, linux,
jdk14...) (optional)</li>
         </ul>
         <p>
  -        So, in Cocoon's case, all our archives shall be called something like:
  +        So, all our archives shall be called something like:
           <em>cocoon-2.0.4-jdk14-bin.tar.gz</em> or <em>cocoon-2.1m1-src.zip</em>
           and so on...
         </p>
         <p>
  -        If one day we ever released some subproject code (for example Lenya), the
  +        Subprojects apply to the same rule, except that of course they add their
  +        project name before the version information. For example for Lenya, the
           name should be along the lines of <em>cocoon-lenya-1.0-bin.tar.gz</em>.
  -        You get the point.
         </p>
       </section>
       <section>
  -      <title>B) The Release Process</title>
  +      <title>The Release Process</title>
         <p>
           This is a step-by-step procedure.
         </p>
         <section>
  -        <title>Code freeze</title>
  +        <title>Code Freeze</title>
           <p>
  -          Prior to the release day, a code freeze should be announced approx. 7 days in
advance.
  +          Prior to the release day, a code freeze should be announced approx. 
  +          seven days in advance.
           </p>
         </section>
         <section>
  -        <title>Announce the release process</title>
  +        <title>Test Phase</title>
           <p>
  -          Send a simple mail to the dev list. This is in order to ensure that 
  +          During the code freeze the whole Cocoon community is invited to test
  +          test distribution, find and fix bugs and update the documentation. if
  +          desired an invitation to the community to help in polishing the release
  +          can be send out to the mailing lists.
  +        </p>
  +      </section>
  +      <section>
  +        <title>Starting the Release Process</title>
  +        <p>
  +          Send a simple mail to the developer list. This is in order to ensure that 
             noone will check in during the release process. If someone checks in 
             during the building, testing and tagging, the release process has to 
  -          be started at the beginning again.
  +          be started at the beginning again. Otherwise the release version is
  +          not the one tagged in CVS.
           </p>
         </section>
  -      <section><title>Get the version</title>
  +      <section>
  +        <title>Get the Version</title>
           <p>
             Check-out a fresh copy from the cvs on a unix platform (this is important, 
             do not use windows!)
           </p>
         </section>
         <section>
  -        <title>Set correct version information</title>
  +        <title>Set Correct Version Information</title>
           <p>
             Change the version information in <em>src/java/org/apache/cocoon/cocoon.properties</em>
             by removing <em>-dev</em> and eventually add new release information
like m1, b1 etc.
  @@ -87,7 +99,7 @@
           </p>
         </section>
         <section>
  -        <title>Build the distrubtion</title>
  +        <title>Build the Distrubtion</title>
           <p>
             Make sure that you make a clean build and that you are really not using windows:
           </p>
  @@ -116,25 +128,45 @@
           </p>
         </section>
         <section>
  -        <title>Continue with the release</title>
  +        <title>Continuing the Release Process</title>
           <p>
             Now check-in the changed version from the first step and tag the release in cvs.
  +          Currently three files should have been changed in the last steps:
           </p>
  +        <ul>
  +          <li><em>src/java/org/apache/cocoon/cocoon.properties</em> :
Version information</li>
  +          <li><em>forrest.properties</em> : Version information</li>
  +          <li><em>blocks.properties</em> : Disable unstable blocks</li>
  +        </ul>
         </section>
         <section>
  -        <title>Start next version</title>
  +        <title>Starting the Next Version</title>
  +        <p>
  +          Change the version in <em>src/java/org/apache/cocoon/cocoon.properties</em>

  +          by increasing the version information and adding "-dev" at the end, 
  +          for example 2.1m3-dev.
  +        </p>
  +        <p>
  +          Change the version in <em>forrest.properties</em> to the same value.
  +        </p>
           <p>
  -          Check the version in <em>src/java/org/apache/cocoon/cocoon.properties</em>
by increasing
  -          the version information and adding "-dev" at the end, for example m3-dev.
  -          Change status.xml by adding the release with proper version and date and start
a
  -          new release section with the placeholders. Add a dummy action here.
  -          And also change the version in forrest.properties
  +          Update the <em>blocks.properties</em> and enable all blocks that
you have
  +          disabled for the release.
  +        </p>
  +        <p>
  +          Change <em>status.xml</em> by adding the release with proper version

  +          and date and start a new release section with placeholders. Add a dummy 
  +          action here.
  +        </p>
  +        <p>
  +          Check-in all these changes.
           </p>
         </section>
         <section>
  -        <title>Sign the release</title>
  +        <title>Signing the Release</title>
           <p>
  -          Therefore you have to put your public key in the KEYS file before! 
  +          Therefore you have to put your public key in the KEYS file (before the 
  +          starting the release process!). 
             In addition create a md5 file for the distribution
           </p>
         </section>
  @@ -145,12 +177,14 @@
           </p>
         </section>
         <section>
  -        <title>Upload the release</title>
  +        <title>Uploading the Release</title>
           <p>
  -          Upload the release and the signatures to www.apache.org and put it
  -          under /www/www.apache.org/dist/cocoon into the correct directories (sources
  -          and binaries). Make sure that you set the permissions correctly.
  +          Upload the release and the signatures to <em>www.apache.org</em>
and put it
  +          under <em>/www/www.apache.org/dist/cocoon</em> into the correct directories

  +          (sources and binaries). Make sure that you set the permissions correctly.
             It's important to give the group write access!
  +        </p>
  +        <p>
             Add/change the links from the cocoon directory to the new version in
             the sources/binaries directory. Update the README.html and the HEADER.html.
             For more information see below.
  @@ -159,8 +193,8 @@
         <section>
           <title>Announcement</title>
           <p>
  -          Announce to the dev list that the release process is finished and end a possible

  -          code freeze.
  +          Announce to the developer list that the release process is finished 
  +          and end a possible code freeze.
           </p>
         </section>
         <section>
  @@ -186,6 +220,12 @@
             Currently it goes to (dev at cocoon.apache.org, users at cocoon.apache.org,
             general at xml.apache.org and announcements at xml.apache.org)
           </p>
  +        <p>
  +          Remember that the locations to mention in any announcements when downloads
  +          are involved is <em>http://cocoon.apache.org/mirror.cgi</em>.
  +          So that people will actually __use__ the mirrors and not peg the Foundation's
  +          bandwidth (which is quite expensive).
  +        </p>
         </section>
         <section>
           <title>Register final version</title>
  @@ -206,7 +246,7 @@
         </section>
       </section>
       <section>
  -      <title>C) Directories</title>
  +      <title>Directories</title>
         <p>
           The only (ONLY) place where distributions shall reside is inside the
           /www/www.apache.org/dist/cocoon on daedalus.apache.org.
  @@ -325,21 +365,6 @@
         <p>
   Note that for release final downloads you shouldn't edit the mirrors.html
   file, as the release should always be linked to cocoon-latest-.....
  -      </p>
  -    </section>
  -    <section>
  -      <title>D) Mirroring and announcing</title>
  -      <p>
  -Once the release is published wait at least 24 hours before announcing it to
  -the mailing lists, so that mirror sites will have the opportunity to pick
  -the changes up and you won't get bugged by people unable to download the
  -distributions.
  -      </p>
  -      <p>
  -Remember that the locations to mention in any announcements when downloads
  -are involved is <em>http://cocoon.apache.org/mirror.cgi</em>.
  -So that people will actually __use__ the mirrors and not peg the Foundation's
  -bandwidth (which is quite expensive).
         </p>
       </section>
     </body>
  
  
  

Mime
View raw message