You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-svn@forrest.apache.org by cr...@apache.org on 2007/04/19 09:40:09 UTC
svn commit: r530301 [2/2] - in /forrest/site: docs_0_90/ procedures/release/
Modified: forrest/site/procedures/release/How_to_release.html
URL: http://svn.apache.org/viewvc/forrest/site/procedures/release/How_to_release.html?view=diff&rev=530301&r1=530300&r2=530301
==============================================================================
--- forrest/site/procedures/release/How_to_release.html (original)
+++ forrest/site/procedures/release/How_to_release.html Thu Apr 19 00:40:08 2007
@@ -277,6 +277,9 @@
<a href="#FinalRel">Finalizing the release</a>
</li>
<li>
+<a href="#prepSite">Prepare the site-author docs for next development phase</a>
+</li>
+<li>
<a href="#UploadAndAnnounce">Upload and announcement</a>
</li>
<li>
@@ -294,9 +297,10 @@
<div class="warning">
<div class="label">Warning</div>
<div class="content">
- This document is still being developed and some steps might need to be
- re-arranged. There are some fixme notes that we will review after this
- release.
+ This document is constantly being developed and some steps will need to be
+ re-arranged. There are some fixme notes that we will review after each
+ release. Do not take this document at face value - always try to visualise the
+ effect of each step.
</div>
</div>
<p>
@@ -313,9 +317,27 @@
and the final testing. Many of the steps can be done only by the Release
Manager.
</p>
+<p>
+ The lead-up to the release is a good opportunity to build the project community
+ and to draw in new developers. The steps in this process try to maximise that.
+ </p>
+<div class="fixme">
+<div class="label">Fixme (open)</div>
+<div class="content">
+ Some of the complexity in this process is due to site-author docs accompanying
+ the release. That is a good thing because then they have local docs.
+ However it complicates this process because the documentation version numbers,
+ xdocs layout, site.xml navigation, etc. all need to be relevant for
+ packing with the release. Trunk needs to stay that way during testing of RCs.
+ Just before the release announcement, certain things need to be updated to
+ create and publish the website. Then following the release, updated to be
+ ready for the next develoment cycle. Much of that process in unavoidable, but
+ some could be simplified.
+ </div>
+</div>
</div>
-<a name="N10021"></a><a name="rm"></a>
+<a name="N10028"></a><a name="rm"></a>
<h2 class="underlined_10">Who is the Release Manager</h2>
<div class="section">
<p>
@@ -342,14 +364,23 @@
assistant would probably hinder.
</p>
<p>
+ The RM needs to have an incredible amount of time and energy available,
+ especially to prepare the first release candidate and to finalise the release.
+ </p>
+<p>
The RM should be comfortable with using SVN and be familiar with the ASF
hardware, with the distribution mirror system, and with ASF release
- procedures. The following notes are terse. If you don't understand, then
+ procedures. Also need to be a quick decision-maker and able to find and solve
+ issues on the spot. It would be nice if others help to solve last minute
+ issues, but don't expect it.
+ </p>
+<p>
+ The following notes are terse. If you don't understand, then
probably not ready to be RM.
</p>
</div>
-<a name="N10037"></a><a name="prep"></a>
+<a name="N10044"></a><a name="prep"></a>
<h2 class="underlined_10">Tasks to be done by the project before the release can start</h2>
<div class="section">
<p>
@@ -366,6 +397,10 @@
<li>The documentation content is ready.</li>
+<li>Plugins have been reviewed and deployed as necessary. Some perhaps need to
+ go through a release process. This should happen independently of the release process.
+ </li>
+
<li>Supporting products (e.g. Ant, Xerces) should have been updated well before this
stage. Do not attempt such upgrades too close to the release, as it
will distract attention from other issues and possibly introduce new problems.
@@ -423,7 +458,7 @@
</div>
</div>
-<a name="N10078"></a><a name="PrepProject"></a>
+<a name="N10088"></a><a name="PrepProject"></a>
<h2 class="underlined_10">Preparing the project for the release</h2>
<div class="section">
<p>
@@ -463,7 +498,7 @@
</ol>
</div>
-<a name="N1009B"></a><a name="PrepRM"></a>
+<a name="N100AB"></a><a name="PrepRM"></a>
<h2 class="underlined_10">Preparations for the Release Manager</h2>
<div class="section">
<p>
@@ -471,7 +506,7 @@
familiar with standard procedures and Apache terminology. This is
crucial for a successful release.
</p>
-<ol>
+<ul>
<li>
<p>
@@ -483,17 +518,24 @@
</p>
</li>
+<li>As discussed above, be sure that you have plenty of time and energy.
+ You will need to be persistent throughout the process.
+ </li>
+
<li>
<p>
- Be familiar with the process of signing releases and generating MD5
+ Be familiar with the process of signing release packages and generating MD5
and PGP. Some more info is at
<a href="http://www.apache.org/dev/release-signing.html">Signing
- Releases</a> and
- <a href="http://forrest.apache.org/mirrors.cgi#verify">http://forrest.apache.org/mirrors.cgi#verify</a>
-
-</p>
+ Releases</a> and our download notes for the
+ <a href="http://forrest.apache.org/mirrors.cgi#verify">Verification</a>.
+ </p>
</li>
+<li>Practice signing email in readiness for the announcment.</li>
+
+<li>Investigate the release procedure notes of other ASF projects.</li>
+
<li>
Make sure that the network connection is reliable and efficient.
</li>
@@ -505,11 +547,19 @@
Forrest works for you.
</p>
</li>
+
+<li>Get a printout of this document to scribble notes as you go.</li>
+
+<li>Use a text file to prepare/record your svn merge commands.</li>
+
+<li>Browse the dev mail list to see what happened around the previous release.
+ Some mails will be useful to glean words to re-use.
+ </li>
-</ol>
+</ul>
</div>
-<a name="N100C3"></a><a name="PrepRelPlan"></a>
+<a name="N100E5"></a><a name="PrepRelPlan"></a>
<h2 class="underlined_10">Preparing the Release Plan</h2>
<div class="section">
<p>
@@ -559,7 +609,7 @@
</div>
</div>
-<a name="N100F6"></a><a name="PrepCodeBase"></a>
+<a name="N10118"></a><a name="PrepCodeBase"></a>
<h2 class="underlined_10">Preparing the code base</h2>
<div class="section">
<p>
@@ -652,7 +702,7 @@
</ol>
</div>
-<a name="N1013C"></a><a name="PrepTrunk"></a>
+<a name="N1015E"></a><a name="PrepTrunk"></a>
<h2 class="underlined_10">Preparing your working copy of SVN trunk</h2>
<div class="section">
<div class="fixme">
@@ -708,7 +758,7 @@
</ol>
</div>
-<a name="N1016A"></a><a name="PrepDistSvn"></a>
+<a name="N1018C"></a><a name="PrepDistSvn"></a>
<h2 class="underlined_10">Preparing the "dist" SVN</h2>
<div class="section">
<p>
@@ -728,7 +778,7 @@
</p>
</div>
-<a name="N1017E"></a><a name="adjustDocs"></a>
+<a name="N101A0"></a><a name="adjustDocs"></a>
<h2 class="underlined_10">Preparing docs for next release cycle</h2>
<div class="section">
<p>
@@ -736,11 +786,19 @@
these changes after the code-freeze, but do not publish to the website
until after the release.
</p>
+<div class="fixme">
+<div class="label">Fixme (dc)</div>
+<div class="content">
+ We definitely need to use automated version number strings where possible.
+ It is too easy to miss some, as we did with 0.8 release.
+ We have a set of core xml entities available.
+ </div>
+</div>
<ol>
<li>
<p>
- Edit "versions" entries in site.xml as follows:
+ Edit site.xml as follows:
</p>
<ol>
@@ -778,6 +836,35 @@
<li>
<p>
+ Further edit site.xml to configure the menu labels. See an example site.xml
+ from a past release. Basically do this ...
+ </p>
+
+<ol>
+
+<li>Add section <v0.90> with minimal content above the <v0.80> section.</li>
+
+<li>Edit the label@ and description@ attributes for each of the three sections.
+ <v0.90> and <v0.80> and <v0.70></li>
+
+<li>Remove the label@ attribute for the <v0.70> section. This prevents
+ it from appearing in the <a href="../../linkmap.html">linkmap ToC</a>.</li>
+
+<li>Remove the whole section <v0.60> of the past docs.</li>
+
+</ol>
+</li>
+
+<li>Edit version numbers in xdocs/versions/index.xml</li>
+
+<li>Edit version numbers in xdocs/pluginDocs/index.xml</li>
+
+<li>Edit version numbers in MOTD section of site-author/skinconf.xml</li>
+
+<li>Edit version numbers in main/fresh-site/..../site.xml and tabs.xml</li>
+
+<li>
+<p>
Remove the past versions (0.6) docs directory by doing 'svn rm
site-author/content/xdocs/docs_0_60
</p>
@@ -787,7 +874,6 @@
<p>
Edit site-author/conf/cli.xconf where it excludes old docs from
being generated (a trick to speed up). Adjust the version numbers.
- Comment-out these exclusions until after the release.
</p>
</li>
@@ -800,42 +886,28 @@
<li>
<p>
- Edit site-author/status.xml:
- </p>
-
-<ol>
-
-<li>
-<p>
- Remove the -dev from the current <release> tag, and set
- the release date.
+ Edit site-author/status.xml to
+ Remove the "-dev" from the current <release> tag, and set
+ the anticipated release date. Remove the "-dev" from the text intro.
</p>
</li>
-
+
+<li>Validate status.xml (e.g. with xmllint).</li>
+
<li>
+
<p>
- Add a new <span class="codefrag">
-<release>
- </span> section for development on the next version e.g. from:
- </p>
-
-<pre class="code">
- <release version="0.8-dev" date="not yet released">
- ...</pre>
-
-<p>
- to:
- </p>
-
-<pre class="code">
- <release version="0.9-dev" date="not yet released">
- ...
- <release>
- <release version="0.8" date="2007-04-16">
- ...</pre>
-</li>
+ Create a new directory as a stub for the next section of development docs.
+ Create a placeholder index page and upgrading notes. See a past release
+ for example. Do this ...
+ </p>
-</ol>
+<pre class="code">
+svn mkdir docs_0_90
+svn copy docs_0_80/index.xml docs_0_90
+svn copy docs_0_80/upgrading.xml docs_0_90
+... edit those docs to suit. Emphasise developers and encourage svn.</pre>
+
</li>
<li>Temporarily remove the "dev" note from upgrading_xy.xml</li>
@@ -847,11 +919,14 @@
</p>
<pre class="code">
- Apache Forrest 0.8 was released on 2007-04-16.
+ Apache Forrest 0.8 was released on 2007-04-18.
[### Add some important new features ###]</pre>
</li>
-<li>Ensure that the documentation is building properly, do 'cd site-author; forrest'. Fix any linking errors.</li>
+<li>Ensure that the documentation is building properly, do 'cd site-author; forrest'.
+ Fix any linking errors. Review changes.html to ensure section numbering.</li>
+
+<li>Edit the site-author/content/doap.xml to add the new release date.</li>
<li>
<p>
@@ -874,7 +949,7 @@
</div>
</div>
-<a name="N101E8"></a><a name="BuildDist"></a>
+<a name="N10228"></a><a name="BuildDist"></a>
<h2 class="underlined_10">Building the release candidate packages</h2>
<div class="section">
<p>
@@ -925,62 +1000,6 @@
<li>
<p>
- Run the following quick tests from the command line of your system
- to ensure that all is well:
- </p>
-
-<ul>
-
-<li>
-<p>
- Change to the main directory and run <span class="codefrag">build test</span>.
- The build should conclude without errors.
- </p>
-</li>
-
-<li>
-<p>
- Change to the site-author directory and run 'forrest'. The docs
- should build without errors.
- </p>
-</li>
-
-</ul>
-
-<p>
- If there are any problems, focus on problems that prevent building
- and invite other commiters to help you solve the problems.
- </p>
-
-<div class="note">
-<div class="label">Note</div>
-<div class="content">
- It is not your job to fix bugs and code freeze should not commence
- with a broken trunk.
- </div>
-</div>
-
-<p>
- If there are bugs with the build system that cannot be easily fixed,
- then call a halt to the release process and start a discussion on
- rescheduling options on the dev-list with the template
- <a href="rc_did_not_build_what_now.txt">rc_did_not_build_what_now.txt</a>
-
-</p>
-</li>
-
-<li>
-<p>
- Remove the build directories from core and plugins. Do <span class="codefrag">svn st
- --no-ignore</span> in the root directory of your release candidate
- directory to be sure that all files created by the test build have
- been removed and no other files have been changed. The status
- command should report no changes.
- </p>
-</li>
-
-<li>
-<p>
Update the version numbers at various places:
</p>
@@ -988,7 +1007,7 @@
<li>
<p>
- Edit main/build.xml and remove the "-dev" text around line 45:
+ Edit main/build.xml and remove the "-dev" text around line 48:
</p>
<pre class="code">
@@ -999,12 +1018,12 @@
</li>
<li>
- Similarly in main/forrest.build.xml around line 32.
+ Similarly in main/forrest.build.xml around line 28.
</li>
<li>
<p>
- Edit plugins/build.xml and increase the docs version number to
+ Edit plugins/build.xml to increase the docs version number to
the next major release. Around line 23:
</p>
@@ -1038,18 +1057,70 @@
</li>
<li>
- Edit 4 files in tools/forrestbar to update the version number to match the new release:
+<p>
+ Run the following quick tests from the command line of your system
+ to ensure that all is well:
+ </p>
+
+<ul>
+
+<li>
+<p>
+ Change to the main directory and run <span class="codefrag">build test</span>.
+ The build should conclude without errors from both seed builds.
+ </p>
+</li>
+
+<li>
+<p>
+ Change to the site-author directory and run 'forrest'. The docs
+ should build without errors.
+ </p>
+</li>
+
+</ul>
+
+<p>
+ If there are any problems, focus on problems that prevent building
+ and invite other commiters to help you solve the problems.
+ </p>
+
+<div class="note">
+<div class="label">Note</div>
+<div class="content">
+ It is not your job to fix bugs and code freeze should not commence
+ with a broken trunk.
+ </div>
+</div>
+
+<p>
+ If there are bugs with the build system that cannot be easily fixed,
+ then call a halt to the release process and start a discussion on
+ rescheduling options on the dev-list with the template
+ <a href="rc_did_not_build_what_now.txt">rc_did_not_build_what_now.txt</a>
+
+</p>
+</li>
+
+<li>
+<p>
+ Remove the build directories from core and plugins. Do <span class="codefrag">svn st
+ --no-ignore</span> in the root directory of your release candidate
+ directory to be sure that all files created by the test build have
+ been removed and no other files have been changed. The status
+ command should report no changes.
+ </p>
+</li>
+
+<li>
+ Edit 3 files in tools/forrestbar to update the version number to match the new release:
<pre class="code">
xpi/install.rdf, line 24: <em:version>0.8<em:version>
xpi/install.js, line 19: var err = initInstall("ForrestBar", "forrestbar", "0.8");
-xpi/chrome/content/contents.rdf, line 28: chrome:displayName="ForrestBar 0.8"/>
+xpi/chrome/content/contents.rdf, line 25: chrome:displayName="ForrestBar 0.8"/>
-xpi/chrome/content/forrestbarOverlay.xul, about line 40 edit the version number
- as well as change the link to point to the new release's docs:
- <menuitem label="Current Docs (0.7)"
- onclick="navigate('http://forrest.apache.org/docs_0_70/index.html');"/>
</pre>
</li>
@@ -1075,6 +1146,16 @@
</li>
<li>
+<p>Cleanup your working copy to remove any extra files.</p>
+
+<pre class="code">
+cd $FORREST_HOME
+find . -name build | xargs rm -rf
+svn status --no-ignore</pre>
+
+</li>
+
+<li>
<p>
Now we will build the release candidate packages for Windows and
Unix.
@@ -1137,12 +1218,12 @@
</p>
<pre class="code">
-svn copy -r ##### -m "Create the ###xy### release branch from r#####" \
+svn copy -r ##### -m "Create the 0.8 release branch from r#####" \
https://svn.apache.org/repos/asf/forrest/trunk \
- https://svn.apache.org/repos/asf/forrest/branches/forrest_###xy###_branch
+ https://svn.apache.org/repos/asf/forrest/branches/forrest_#xy#_branch
where
- 'xy' is a compact form of the version (e.g. 04, 041, 05).
+ '#xy#' is a compact form of the version (e.g. 04, 041, 05).
'#####' is the SVN revision number that the branch was created from,
which was the revision that the release candidate packages were generated from.
(Remember that you recorded this number earlier.)
@@ -1158,7 +1239,7 @@
</ol>
</div>
-<a name="N1029F"></a><a name="vote"></a>
+<a name="N102E8"></a><a name="vote"></a>
<h2 class="underlined_10">Testing the release candidate and voting</h2>
<div class="section">
<p>
@@ -1195,6 +1276,8 @@
distribution at README.txt and index.html</li>
<li>Encourage people to build some difficult sites.</li>
+
+<li>Remind people about how long remains for testing.</li>
</ul>
</li>
@@ -1208,7 +1291,8 @@
</li>
<li>If necessary start again with <a href="#BuildDist">Building the packages</a> and build another
- release candidate.</li>
+ release candidate. Remember to do 'svn update' first and to record the
+ new SVN revision number.</li>
<li>Tally the votes and report the result to the dev list.</li>
@@ -1222,7 +1306,7 @@
</div>
</div>
-<a name="N102D7"></a><a name="FinalRel"></a>
+<a name="N10323"></a><a name="FinalRel"></a>
<h2 class="underlined_10">Finalizing the release</h2>
<div class="section">
<p>
@@ -1232,9 +1316,15 @@
<ol>
<li>
+ Remove the release candidate packages from your public_html
+ directory.
+ </li>
+
+<li>
<p>
If there have been changes to the trunk since the branch was
- created, then merge trunk to branch.
+ created, then merge trunk to branch. Remember to use a proper commit message
+ which includes the revision number used for the merge (see the SVN Book).
</p>
<div class="fixme">
@@ -1262,19 +1352,19 @@
Tag SVN by doing:
</p>
-<pre class="code">svn copy -m "Create tag forrest_###xy### from release branch" \
+<pre class="code">svn copy -m "Create tag forrest_###xy###_release from release branch" \
https://svn.apache.org/repos/asf/forrest/branches/forrest_###xy###_branch \
- https://svn.apache.org/repos/asf/forrest/tags/forrest_###xy###</pre>
+ https://svn.apache.org/repos/asf/forrest/tags/forrest_###xy###_release</pre>
<p>
- where 'xy' is a compact (without the dots) form of the version
+ where '###xy###' is a compact (without the dots) form of the version
number (e.g. 04, 041, 05).
</p>
<p>
See
<a href="http://svn.apache.org/repos/asf/forrest/tags/">http://svn.apache.org/repos/asf/forrest/tags/</a>
- for examples of past tags, e.g. forrest_07
+ for examples of past tags, e.g. forrest_08_release
</p>
<div class="fixme">
@@ -1292,12 +1382,12 @@
Tag the "site" SVN by doing:
</p>
-<pre class="code">svn copy -m "Create tag forrest_###xy### release" \
+<pre class="code">svn copy -m "Create tag forrest_###xy###_release_site from site" \
https://svn.apache.org/repos/asf/forrest/site \
- https://svn.apache.org/repos/asf/forrest/tags/forrest_###xy###</pre>
+ https://svn.apache.org/repos/asf/forrest/tags/forrest_###xy###_release_site</pre>
<p>
- where 'xy' is a compact (without the dots) form of the version
+ where '###xy###' is a compact (without the dots) form of the version
number (e.g. 04, 041, 05).
</p>
</li>
@@ -1313,12 +1403,118 @@
</ol>
</div>
-<a name="N10319"></a><a name="UploadAndAnnounce"></a>
+<a name="N10368"></a><a name="prepSite"></a>
+<h2 class="underlined_10">Prepare the site-author docs for next development phase</h2>
+<div class="section">
+<div class="note">
+<div class="label">Note</div>
+<div class="content">
+ Before doing anything, skip to the next section to get the upload commenced.
+ </div>
+</div>
+<p>
+ While waiting for the mirrors to catch up, you will copy the docs set for the
+ next development, then call off the code-freeze. Do this ...
+ </p>
+<ul>
+
+<li>Create a copy of current dev-docs in trunk for the next development phase ...
+ <pre class="code">
+cd site-author/content/xdocs
+svn copy docs_0_80 docs_0_90
+svn copy pluginDocs/plugins_0_80 plugins_0_90</pre>
+
+</li>
+
+<li>Edit site.xml and add a copy of the most current versioned section (e.g. <v0.80>) above it.
+ Increment the first decimal of the sections name to reflect the next planned release (e.g. <v0.90>).
+ </li>
+
+<li>
+<p>Edit site-author/status.xml to add a new <span class="codefrag">
+<release>
+ </span> section above it for development on the next version.
+ Add one placeholder action for the next "upgrading" doc.
+ Do the same in the release branch for a possible x.y.1
+ </p>
+
+<pre class="code">
+ <release version="0.9-dev" date="not yet released">
+ <introduction>
+ ...
+ </release>
+ <release version="0.8" date="2007-04-18">
+ <action
+ ...</pre>
+</li>
+
+<li>Return the "dev" note to upgrading_xy.xml and add some of the orginal
+ general points that still apply.</li>
+
+<li>Edit site-author/conf/cli.xconf to exclude the old docs again.</li>
+
+<li>Add new plugins directories to the "forrest/site" SVN ...
+ <pre class="code">
+svn mkdir pluginDocs/plugins_0_90
+svn mkdir plugins/0.9</pre>
+</li>
+
+<li>
+<p>
+ Edit main/build.xml, increment the version and add a -dev tag:
+ around line 45: <property name="version" value="0.9-dev"/>
+ </p>
+</li>
+
+<li>
+<p>
+ Edit main/forrest.build.xml and update the version: around line 32:
+ </p>
+
+<pre class="code"><property name="version" value="0.9-dev"/></pre>
+</li>
+
+<li>Edit version numbers in plugins/build.xml</li>
+
+<li>Edit version numbers in tools/forrestbar</li>
+
+<li>
+<p>
+ Update the .htaccess file to redirect /docs/dev/ to the next
+ version, and do other changes noted in the .htaccess file. See
+ site-author/content/.htaccess
+ </p>
+
+<div class="fixme">
+<div class="label">Fixme (fso)</div>
+<div class="content">
+ Need to go through .htaccess and clean up.
+ </div>
+</div>
+</li>
+
+<li>
+ Update the release version number and release date in xdocs/index.xml
+ and site-author/content/doap.xml
+ </li>
+
+<li>Commit all of the above changes.</li>
+
+<li>Send email to the dev list to remind people about the new docs set docs_0_90
+ and that we don't update docs_0_60 set. Also remind about the new release branch
+ of svn. See example email from the 0.8 release.</li>
+
+</ul>
+</div>
+
+<a name="N103BC"></a><a name="UploadAndAnnounce"></a>
<h2 class="underlined_10">Upload and announcement</h2>
<div class="section">
<p>
In this phase we'll upload the new Release, wait for it to be available
- on most mirror sites, then announce the new release.
+ on most mirror sites, publish the new website, then announce the release.
+ The reason for waiting, is because when you send the announcement, most of
+ the mirrors need to be up-to-date or your audience will grumble.
</p>
<div class="note">
<div class="label">Note</div>
@@ -1334,15 +1530,12 @@
<p>
Use scp to upload the release: the *.tar.gz, the *.zip, the *.asc
and *.md5 files, and the RELEASE-NOTES-0.8.txt to people.apache.org
- at /www/www.apache.org/ dist/forrest/
+ at /www/www.apache.org/ dist/forrest/ directory.
</p>
<p>
Ensure correct file permissions by executing <span class="codefrag">'chgrp forrest
- *'</span> then <span class="codefrag">'chmod 664 *'</span> in that directory.
- </p>
-
-<p>
+ *'</span> then <span class="codefrag">'chmod g+w *'</span> in that directory.
Each PMC member has a server account and belongs to the forrest
group.
</p>
@@ -1378,11 +1571,13 @@
<p>
For some mirrors, this takes only a few hours. However others are
- slow. How long to wait is a tradeoff, e.g. 8 hours.
+ slow. How long to wait is a tradeoff, e.g. 8 hours has been the norm.
</p>
<p>
See <a href="http://www.apache.org/mirrors/">Status of mirrors</a>.
+ It is a very useful service and fun to watch. See the "age histogram"i
+ near the bottom.
</p>
<p>
@@ -1396,45 +1591,33 @@
</p>
</li>
-<li>Create a copy of current dev-docs in trunk for the next development phase.
- Do 'cd site-author/content/xdocs' and 'svn copy docs_0_80 docs_0_90'
- </li>
-
-<li>Open site.xml and add a copy of the most current versioned section (e.g. <v0.80>) above it.
- Increment the first decimal of the sections name to reflect the next planned release (e.g. <v0.90>).
- </li>
-
-<li>
-<p>
- Update the .htaccess file to redirect /docs/dev/ to the next
- version, and do other changes noted in the .htaccess file. See
- site-author/content/.htaccess
- </p>
-
-<div class="fixme">
-<div class="label">Fixme (fso)</div>
-<div class="content">
- Need to go through .htaccess and clean up.
- </div>
-</div>
-</li>
-
-<li>
- Update the release version number and release date in our DOAP file.
- See site-author/content/doap.xml
- </li>
+<li>Ensure that docs are *not* being excluded via site-author/conf/cli.xconf
+ as we need to re-build the whole site.</li>
-<li>Commit all of the above changes.</li>
+<li>Before re-building and deploying the new website, check the time.
+ Remember that an 'svn up' happens our on server just after the hour, then
+ a bit later the rsync happens and the site is live about 20 minutes past.
+ This site deployment will take some time, mostly because you are actually
+ doing a fresh installation of a local forrestbot (it does 'svn co forrest/site').
+ </li>
<li>
<p>
- Rebuild (Forrest site) and publish the Forrest website as normal. Be
+ Re-build and publish the Forrest website as normal. Be
sure to use the new version of trunk for building the docs. Refer to
<a href="../../procedures/How_to_publish_docs.html">Publishing Forrest Documentation</a>
- for details.
+ for details. Beware, there is a forrestbot bug whereby with a brand new
+ forrest installation, the first deploy only does the added files. So deploy again.
</p>
</li>
+<li>Test the new Forrest <a href="http://forrest.apache.org/">website</a>
+ and the redirects
+ <a href="http://forrest.apache.org/docs/">f.a.o/docs/</a> and
+ <a href="http://forrest.apache.org/docs/dev/">f.a.o/docs/dev/</a> and the
+ <a href="http://forrest.apache.org/mirrors.cgi">download</a> page.
+ </li>
+
<li>
<p>
Update the xml.apache.org website (Forrest is part of the Apache XML
@@ -1448,10 +1631,9 @@
<li>
<p>
- Send <a href="announce_release.txt">announce_release.txt</a>as email
- to 'dev@forrest.apache.org', 'user@forrest.apache.org',
- 'announce@apache.org', 'announcements@xml.apache.org'. Sign the
- email (e.g. PGP).
+ Send <a href="announce_release.txt">announce_release.txt</a> as email to
+ the Forrest user and dev list and the ASF-wide announce lists.
+ Sign the email (e.g. PGP).
</p>
<p>
@@ -1461,31 +1643,35 @@
<ul>
<li>
-<a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=103746673310573">0.2</a>
+<a href="http://marc.info/?l=xml-apache-announce&m=103746673310573">0.2</a>
+</li>
+
+<li>
+<a href="http://marc.info/?l=xml-apache-announce&m=104399934113331">0.3 </a>
</li>
<li>
-<a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=104399934113331">0.3 </a>
+<a href="http://marc.info/?l=jakarta-announce&m=104510734501302">0.4</a>
</li>
<li>
-<a href="http://marc.theaimsgroup.com/?l=jakarta-announce&m=104510734501302">0.4</a>
+<a href="http://marc.info/?l=xml-apache-announce&m=106352706005681">0.5</a>
</li>
<li>
-<a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=106352706005681">0.5</a>
+<a href="http://marc.info/?l=xml-apache-announce&m=106541447606765">0.5.1</a>
</li>
<li>
-<a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=106541447606765">0.5.1</a>
+<a href="http://marc.info/?l=xml-apache-announce&m=109784461425740">0.6</a>
</li>
<li>
-<a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=109784461425740">0.6</a>
+<a href="http://marc.info/?l=xml-apache-announce&m=111960678028211">0.7</a>
</li>
<li>
-<a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=111960678028211">0.7</a>
+<a href="http://marc.info/?l=apache-announce&m=117688881228702">0.8</a>
</li>
</ul>
@@ -1507,32 +1693,11 @@
</ol>
</div>
-<a name="N103C6"></a><a name="cleanup"></a>
+<a name="N10470"></a><a name="cleanup"></a>
<h2 class="underlined_10">Cleanup</h2>
<div class="section">
<ol>
-<li>
-<p>
- Edit main/build.xml, increment the version and add a -dev tag:
- around line 45: <property name="version" value="0.9-dev"/>
- </p>
-</li>
-
-<li>
-<p>
- Edit main/forrest.build.xml and update the version: around line 32:
- </p>
-
-<pre class="code"><property name="version" value="0.9-dev"/></pre>
-</li>
-
-<li>Return the "dev" note to upgrading_xy.xml</li>
-
-<li>Edit site-author/conf/cli.xconf to exclude the old docs again.</li>
-
-<li>Commit all of the above changes.</li>
-
<li>Remove the old generated docs from SVN forrest/site/docs_0_60
which removes them from the website.
</li>
@@ -1544,13 +1709,11 @@
archive.apache.org/dist/forrest/
</p>
</li>
-
-<li>Create a new plugins directory in the forrest/site SVN for the
- next development phase:
- <pre class="code">
-svn mkdir https://svn.apache.org/repos/asf/forrest/site/plugins/0.9
- </pre>
-</li>
+
+<li>Tidy up any "site:v0.7" references. These will refer to old documentation
+ that will be removed at the next release. Especially status.xml file will
+ have such. Generalise as many as possible.
+ </li>
<li>
<p>
@@ -1577,30 +1740,21 @@
<li>
<p>
Mark 0.8 as released using "Manage Versions".
- </p>
-</li>
-
-<li>
-<p>
- Review the Issues for the old version and move any Incomplete
- ones up.
+ Review the Issues for the old version.
</p>
</li>
</ol>
</li>
-<li>
-<p>
- Remove the release candidate packages from your public_html
- directory.
- </p>
-</li>
+<li>Deploy the Forrest site again. It will automatically rebuild the
+ <a href="../../forrest-issues.html">Open Issues</a> page.
+ </li>
</ol>
</div>
-<a name="N1040D"></a><a name="conclusion"></a>
+<a name="N1049E"></a><a name="conclusion"></a>
<h2 class="underlined_10">Conclusion</h2>
<div class="section">
<p>
Modified: forrest/site/procedures/release/How_to_release.pdf
URL: http://svn.apache.org/viewvc/forrest/site/procedures/release/How_to_release.pdf?view=diff&rev=530301&r1=530300&r2=530301
==============================================================================
Binary files - no diff available.
Modified: forrest/site/procedures/release/test_and_vote_on_rel_cand.txt
URL: http://svn.apache.org/viewvc/forrest/site/procedures/release/test_and_vote_on_rel_cand.txt?view=diff&rev=530301&r1=530300&r2=530301
==============================================================================
--- forrest/site/procedures/release/test_and_vote_on_rel_cand.txt (original)
+++ forrest/site/procedures/release/test_and_vote_on_rel_cand.txt Thu Apr 19 00:40:08 2007
@@ -7,16 +7,15 @@
We need people to test the release candidate on your projects,
especially on different operating systems and Java version.
Just send a short reply to this thread that it works for you.
-See method below.
+See testing hints below.
Download the release candidate and supporting files:
-http://people.apache.org/~[### your apache ID ###]/release-forrest-08/
+http://people.apache.org/~[### your apache ID ###]/temp/forrest-###08###-rc1/
For Windows get *.zip md5sum ################################
For UNIX get *.tar.gz md5sum ################################
Get the *.asc and *.md5 that match your chosen download.
-It was packed from SVN revision ####
Java [### JavaVersion ###] or later is required.
Testing and vote period concludes [#### Date #####] [2].
@@ -24,7 +23,8 @@
However only the PMC votes are binding [3].
When voting, quote the md5sum to ensure that we are all
-using the correct release candidate package.
+using the correct release candidate package. The votes
+need to happen against the final release package.
PMC members need to satisfy themselves that the actual
final release package meets the ASF principles.