forrest-svn mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cross...@apache.org
Subject svn commit: r408800 [1/2] - /forrest/trunk/site-author/content/xdocs/procedures/release/
Date Tue, 23 May 2006 00:32:09 GMT
Author: crossley
Date: Mon May 22 17:32:08 2006
New Revision: 408800

URL: http://svn.apache.org/viewvc?rev=408800&view=rev
Log:
Fix DOS line-ending and do 'svn propset svn:eol-style native'.

Modified:
    forrest/trunk/site-author/content/xdocs/procedures/release/How_to_release.xml   (contents, props changed)
    forrest/trunk/site-author/content/xdocs/procedures/release/announce_end_of_code_freeze.txt   (contents, props changed)
    forrest/trunk/site-author/content/xdocs/procedures/release/announce_release.txt   (contents, props changed)
    forrest/trunk/site-author/content/xdocs/procedures/release/anounce_code_freeze.txt   (contents, props changed)
    forrest/trunk/site-author/content/xdocs/procedures/release/propose_release_plan.txt   (contents, props changed)
    forrest/trunk/site-author/content/xdocs/procedures/release/rc_did_not_build_what_now.txt   (contents, props changed)
    forrest/trunk/site-author/content/xdocs/procedures/release/test_and_vote_on_rel_cand.txt   (contents, props changed)

Modified: forrest/trunk/site-author/content/xdocs/procedures/release/How_to_release.xml
URL: http://svn.apache.org/viewvc/forrest/trunk/site-author/content/xdocs/procedures/release/How_to_release.xml?rev=408800&r1=408799&r2=408800&view=diff
==============================================================================
--- forrest/trunk/site-author/content/xdocs/procedures/release/How_to_release.xml (original)
+++ forrest/trunk/site-author/content/xdocs/procedures/release/How_to_release.xml Mon May 22 17:32:08 2006
@@ -1,675 +1,676 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!--
-  Copyright 2006 The Apache Software Foundation or its licensors,
-  as applicable.
-
-  Licensed under the Apache License, Version 2.0 (the "License");
-  you may not use this file except in compliance with the License.
-  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
--->
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
-  "http://forrest.apache.org/dtd/document-v20.dtd">
-<document>
-    <header>
-        <title>How to Release Forrest</title>
-        <abstract>This documents the steps that the Release Manager (RM) should follow when doing a Forrest
-        release.</abstract>
-    </header>
-    <body>
-
-        <section id="About">
-            <title>About this Document</title>
-            <p>This documents the steps that the Release Manager (RM) should follow when doing a Forrest release. Note
-                that it might have mistakes - we seem to discover something new each time and some steps might need to
-                happen in a different order. Fine tune these notes for next time. Do some practice runs.</p>
-
-            <p>There are some steps that other committers, and even developers, can assist with, especially in the areas
-                of getting ready for the release and the final testing. Many of the steps can be done only by the
-                Release Manager.</p>
-
-            <p>It is not the Release Manager's job to fix bugs nor address blocker issues. The RM job begins when the
-                project is ready to do the release.</p>
-        </section>
-
-        <section id="PrepProject">
-            <title>Preparing the Project for the release</title>
-            <ol>
-                <li>
-                    <p>The Release Manager (RM) starts the process to finalise the outstanding blocker issues. </p>
-                    <p>Check and make sure the following preconditions are met:</p>
-                    <ul>
-                        <li>
-                            <p>Has the project prepared or updated the Roadmap to schedule the realistic Issues?</p>
-                        </li>
-                        <li>
-                            <p>Has the project made good progress towards fixing the Blockers and applying the
-                                outstanding patches?</p>
-                        </li>
-                    </ul>
-                    <p>If not, then the project is not yet ready for release. Remember that it
-                      is not the RM's job to do this.</p>
-                    <p>If so, then send an email to get the project to decide what to do with the remaining issues. Propose to
-                        delay some issues to a future release, encourage people to fix others. See <a
-                            href="http://issues.apache.org/jira/browse/FOR-853">FOR-853</a>. Look at <a
-                            href="http://www.mail-archive.com/dev@forrest.apache.org/msg02310.html">msg02310.html</a>
-                        for an example of such a message.</p>
-
-                </li>
-                <li>
-                    <p>Start discussion on Java-Version to use for compiling and testing the release.</p>
-                </li>
-            </ol>
-        </section>
-
-        <section id="PrepTeam">
-            <title>Preparations for the Release Team</title>
-            <p>Particularly the Release Manager, but also anyone assisting, needs to be familiar
-              with standard procedures and Apache terminology. This is crucial for a successful release.</p>
-            <ol>
-                <li>
-                    <p>If you have never done a release before or need to refresh your memory, read all about Apache
-                        Releases in general at <a href="http://www.apache.org/dev/#releases"
-                            >http://www.apache.org/dev/#releases</a>. Make sure any assistants have read and understood
-                        this as well.</p>
-                </li>
-                <li>
-                    <p>Make sure every team member is familiar with the process of signing releases and generating MD5
-                        and PGP. You'll find some more info 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>
-                </li>
-                <li>
-                    <p>Ensure that as many PMC members as possible have their PGP keys in the KEYS file in Forrest's
-                        root directory. Instructions on how to add keys are included in that file. Instructions on how to
-                        create and manage pgp-keys can be found at the abovementioned references.</p>
-                </li>
-                <li>
-                    <p>Make sure every team member has downloaded and installed the Java-Version to use for compiling
-                        the release. Downloading and installing that version should be done well ahead of time to avoid
-                        delays.</p>
-                </li>
-
-            </ol>
-        </section>
-
-        <section id="PrepRelPlan">
-            <title>Prepare the Release Plan</title>
-            <p>Prepare the Release Plan to define the corner stones of the coming release</p>
-            <ol>
-                <li>Java-Version to test this release</li>
-                <li>Start of code-freeze</li>
-                <li>Start of test-period</li>
-                <li>Vote on release candidate</li>
-                <li>Optional creation of release candidate #2 (when there are bugs)</li>
-                <li>Start of test-period #2</li>
-                <li>Vote on release candidate #2</li>
-                <li>Scheduled release Date</li>
-            </ol>
-
-            <p>Use the email template <a href="propose_release_plan.txt">propose_release_plan.txt</a> to write and
-                propose your plan, then call for a quick vote on the release plan on the dev list.</p>
-            <note>There are various reasons for voting on the Release Plan, e.g. makes people aware that a code-freeze
-                is about to happen; encourage them to get involved with the release; ensure that the date is suitable
-                and people will be around to test and then vote on the actual release. See a good discussion <a
-                    href="http://marc.theaimsgroup.com/?t=114296877800003">in the archives</a>
-            </note>
-        </section>
-
-        <section id="PrepCodeBase">
-            <title>Preparing the Code Base</title>
-            <ol>
-                <li>
-                    <p>Ensure that there are no copyright issues. The committers and PMC would have been continually
-                        monitoring this. There are some tools to assist with scanning for issues, e.g. <a
-                            href="svn:committers/relicense/src/perl/relicense.txt"
-                            >svn:committers/relicense/src/perl/relicense.txt</a> and <a href="svn:committers/tools/"
-                            >svn:committers/tools/</a>
-                    </p>
-                </li>
-                <li>
-                    <p>Ensure that the line-endings and svn:eol-style property are correct for all files. See <a
-                            href="svn:committers/tools/">svn:committers/tools/</a></p>
-                </li>
-                <li>
-                    <p>Ensure that documentation is ready.</p>
-                </li>
-                <li>
-                    <p>Ensure that all relevant plugins have been deployed to plugins/0.8-dev/ See other notes at
-                        plugins/RELEASE_PROCESS.txt</p>
-                    <fixme author="fso">Check and integrate plugins/RELEASE_PROCESS.txt as a new document.</fixme>
-                </li>
-            </ol>
-        </section>
-
-        <section id="PrepNewBranch">
-            <title>Prepare Release Branch</title>
-
-            <fixme author="fso">We need to discuss order from here on. My idea is to adjust docs before we enter code
-                freeze to save time later. But if the rc fails and release is postponed might need to roll back changes
-                easily and - if possible - roll them forward later. So creating an svn branch for the rc seems to make
-                sense to me. Also: For more than one person working on building the release for different OS it would
-                also be good to have all the changes in svn committed already rather than doing it later. Probably
-                easiest would be to create an rc branch here and co that. I'd sacrifice the alternative approach for
-                that which is far too risky for my liking anyway. wdyt?</fixme>
-
-            <p>In this step you check out a fresh copy from SVN to make sure you have no local modifications, especially
-                those that might be hidden by svn:ignore settings. It will soon become the release branch.</p>
-            <note>This step is actually just preparation to keep code-freeze period as short as possible.</note>
-            <ol>
-                <li>
-                    <p>Create a new empty directory 'Forrest_Release' on your system and make it the current
-                    directory.</p>
-                </li>
-                <li>
-                    <p>Start <code>svn co https://svn.apache.org/repos/asf/forrest/trunk</code> from the command-line of
-                        your system or the equivalent for the svn-tool you use.</p>
-                </li>
-            </ol>
-
-            <note>This will take quite a while if you are on a dial-up connection. See alternatives below.</note>
-
-            <p>Alternative Approach</p>
-
-            <ol>
-                <li> Do 'svn update -r HEAD' to ensure that you are up-to-date. </li>
-                <li> Run 'svn status --no-ignore' </li>
-                <li>
-                    <p>Delete any extra files you might have added/changed in your local copy. <strong>They must not be
-                            packed with the release.</strong> It must be a pristine copy of the current trunk.</p>
-                </li>
-            </ol>
-            <warning>This approach requires a good understanding of svn and how it works. It is not as automatic and
-                safe as the method above.</warning>
-        </section>
-
-        <section id="adjustDocs">
-            <title>Prepare Docs for next release cycle</title>
-
-            <fixme author="">I'd suggest the following steps to keep build size small and simplify procedure:</fixme>
-
-
-            <ol>
-                <li>
-                    <p>Edit version subtabs in site.xml as follows:</p>
-
-                    <ol>
-                        <li>
-                            <p>Move all version numbers one line down so that </p>
-                            <source>
-                                <![CDATA[
- <versions tab="docs">
-    <overview label="Overview" href="versions/index.html"/>
-    <v0.8 label="0.8-dev" href="site:v0.80//index"/>
-    <v0.7 label="0.7 (current)" href="site:v0.70//index"/>
-    <v0.6 label="0.6" href="site:v0.60//index"/>
-  </versions>
-                        ]]>
-                            </source>
-                            <p>becomes</p>
-                            <source>
-                                <![CDATA[
- <versions tab="docs">
-    <overview label="Overview" href="versions/index.html"/>
-    <v0.9 label="0.9-dev" href="site:v0.90//index"/>
-    <v0.8 label="0.8 (current)" href="site:v0.80//index"/>
-    <v0.7 label="0.7" href="site:v0.70//index"/>
-  </versions>
-                        ]]></source>
-                        </li>
-                    </ol>
-                </li>
-                <li>
-                    <p>Remove past versions (0.6) docs-directory from svn branch.</p>
-                    <fixme author="fso">find and list svn-command</fixme>
-
-                </li>
-                <li>
-                    <p>Adjust version-numbers in site.xml.</p>
-                    <fixme author="fso">This used to be 'Do global replace throughout docs_0_80 to replace the string
-                        ="site:v0.70 with ="site:v0.80' but this needs checking.</fixme>
-                    
-                </li>
-                
-
-
-
-                <li>
-                    <p>Edit site-author/status.xml:</p>
-                    <ol>
-                        <li>
-                            <p>Remove the -dev from the current &lt;release&gt; tag, and set the release
-                            date.</p>
-                        </li>
-                        <li>
-                            <p>Add a new &lt;release&gt; for development on the next version e.g. from:
-                                &lt;release version=&quot;0.7-dev&quot; date=&quot;not yet
-                                released&quot;&gt; ... to: &lt;release version=&quot;0.8-dev&quot;
-                                date=&quot;not yet released&quot;&gt; &lt;/release&gt;
-                                &lt;release version=&quot;0.7&quot;
-                                date=&quot;2002-02-13&quot;&gt; ...</p>
-                        </li>
-                    </ol>
-
-
-                </li>
-                <li>
-                    <p>Edit the forrest/site-author/content/xdocs/mirrors.html and adjust all version-specific content.</p>
-                    <fixme author="">FIXME: There is a bug (FOR-300) in the forrest build which generates to
-                        main/site/mirrors.html instead of build/site/mirrors.html</fixme>
-                </li>
-                <li>
-                    <p>Edit the Forrest home page in the "News and events" section and add a text like:</p>
-                    <source> Apache Forrest 0.xx was released on [Date]. [Important new features] </source>
-                </li>
-                <li>
-                    <p> Rename the deployed plugins directory by issuing the following commands at the command line </p>
-                    <source> cd /svn/asf/forrest-site svn up svn mv plugins/0.8-dev plugins/0.8 svn mkdir
-                        plugins/0.9-dev svn commit</source>
-                    <fixme author="fso">Issue them where and to what end?</fixme>
-                </li>
-                
-
-            </ol>
-        </section>
-
-        <section id="BuildDist">
-            <title>Building the distribution</title>
-            <p>In this phase you build the release candidate to be tested.</p>
-            <note>You can practice the following steps (as far as creating the branch) without committing anything even
-                before code-freeze. This ensures a good release candidate.</note>
-            <ol>
-                <li>Use template <a href="anounce_code_freeze.txt">anounce_code_freeze.txt</a> to send a reminder-mail
-                    to dev-list when the code-freeze commences.</li>
-                <li>
-                    <p>Update your release checkout (svn up) to include last minute changes.</p>
-                </li>
-                <li> </li>
-                <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 <code>build test</code>. 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>
-                    <note>It is not your job to fix bugs and code freeze should not commence with a broken trunk.</note>
-                    <p>If there are bugs 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 <code>svn st --no-ignore</code> 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>
-                    <ul>
-                        <li>
-                            <p>Edit main/build.xml and replace the '-dev' text with '' i.e. nothing: around line 45:
-                                &lt;property name=&quot;forrest.version&quot;
-                                value=&quot;0.7-dev&quot;/&gt; to: &lt;property
-                                name=&quot;forrest.version&quot; value=&quot;0.7&quot;/&gt; </p>
-                        </li>
-
-                        <li>
-                            <p>Edit main/forrest.build.xml to update the version tag to remove "-dev". There are two
-                                occurences: around line 32: &lt;property name=&quot;forrest.version&quot;
-                                value=&quot;0.7-dev&quot;/&gt; ^^^^ around line 60:
-                                &lt;description&gt; | Forrest Site Builder | | 0.7-dev | ^^^^</p>
-                        </li>
-                        <li>
-                            <p>Edit plugins/build.xml and increase the docs version number to the next major release:
-                                around line 23: &lt;property name=&quot;forrest.version&quot;
-                                value=&quot;0.7&quot;/&gt; to: &lt;property
-                                name=&quot;forrest.version&quot; value=&quot;0.8&quot;/&gt; </p>
-                            <note>This is deliberately a major version up. It is assumed that plugins will be developed
-                                against the next version of Forrest. Individual plugins can override this property in
-                                their own build files.</note>
-                        </li>
-                    </ul>
-
-                </li>
-                <li>
-                    <p>Ensure that each plugin that uses the locationmap has its "release version" set to 0.8 or
-                    more.</p>
-                </li>
-                <li>
-                    <p>Edit 4 files in tools/forrestbar to update the version number to match the new release: -
-                        install.rdf, line 24: &lt;em:version&gt;0.7&lt;/em:version&gt; - install.js,
-                        line 19: var err = initInstall("ForrestBar", "forrestbar", "0.7"); -
-                        xpi/chrome/content/contents.rdf, line 27: chrome:displayName="ForrestBar 0.7"/> -
-                        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: &lt;menuitem label=&quot;Current
-                        Docs (0.7)&quot;
-                        onclick=&quot;navigate(&apos;http://forrest.apache.org/docs_0_70/index.html&apos;);&quot;
-                        /&gt; </p>
-                    <fixme author="">There are probably other areas which have version numbers. How can we improve this?</fixme>
-
-                    <fixme author="">Not sure at what stage we get rid of the old docs, e.g. 0.6</fixme>
-                    <fixme author="">Not sure at what stage need to edit site-author/content/xdocs/mirrors.html (Presume
-                        that it should be done after packing release. See below.)</fixme>
-
-                </li>
-                <li>
-                    <p>Create a new file, etc/RELEASE-NOTES-x.y.txt, where x.y is the version currently being released.
-                        It is best to copy an earlier RELEASE-NOTES file, to keep a common layout. In this file, provide
-                        a summary of changes, and check for general accuracy. Scan the status.xml/changes and the
-                        Roadmap via the issues tracker, to find the important issues. </p>
-                </li>
-                <li>
-                    <p>Set your Java version to be the lowest specified of our supported versions.</p>
-                    <note> Set the environment variable JAVA_HOME to the path of the Java version. Note for Windows: If
-                        you change the setting in system properties, you need to logout and login again for the changes
-                        to become effective.</note>
-                </li>
-                <li>
-                    <p>Take note of the SVN revision number of your trunk by running <code>svn info</code> from the
-                        command line in the Release Candidates root dir and look at the "Last Changed Rev: ######".</p>
-                    <fixme author="">What is this used for?</fixme>
-                </li>
-                <li>
-                    <p>Now we will build the release candidates for Windows and Unix.</p>
-                    <note>The reason for creating two separate archives is the line-endings dilemma between Windows and
-                        UNIX. SVN ensures correct line-endings on each operating system (as long as committers have been
-                        diligent when adding/updating the repository).</note>
-                    <ul>
-                        <li>
-                            <p>On a UNIX machine:<br /> Change to directory main and run <code>build release-dist</code>
-                                to generate the distributions on a UNIX machine.</p>
-                            <p> Two archives are created: apache-forrest-X.Y.tar.gz apache-forrest-X.Y.zip. Ignore the
-                                *.zip archive.</p>
-                            <p>Unpack and test the relevant archive in a fresh new directory.</p>
-                        </li>
-                        <li>
-                            <p>On a Windows machine:<br /> Change to directory main and run <code>build
-                                release-dist</code> to generate the distributions on a UNIX machine.</p>
-                            <p> Two archives are created: apache-forrest-X.Y.tar.gz apache-forrest-X.Y.zip. Ignore the
-                                *.tar.gz archive.</p>
-                            <p>Unpack and test the relevant archive in a fresh new directory.</p>
-                        </li>
-
-                    </ul>
-                </li>
-                <li>
-                    <p id="signing">Sign the Release Candidates distribution file and the *.asc and *.md5 files.</p>
-                    <p>Here is one example when using <a href="http://www.gnupg.org/(en)/download/index.html">gpg</a>
-                        and openssl from the command line. </p>
-                    <note>An windows version for openssl can be found at <a
-                            href="http://www.slproweb.com/products/Win32OpenSSL.html"
-                            >http://www.slproweb.com/products/Win32OpenSSL.html</a></note>
-                    <source><![CDATA[
-        gpg --recv-key <myKey>
-        gpg --output crossley-apache-forrest-0.7-RC1.tar.gz.asc \
-        --detach-sig --armor apache-forrest-0.7-RC1.tar.gz
-        gpg --verify crossley-apache-forrest-0.7.tar.gz.asc \
-        apache-forrest-0.7-RC1.tar.gz]]></source>
-                    <p> ... should say "Good signature from ..."</p>
-
-                    <source><![CDATA[
-        openssl dgst -md5 -out apache-forrest-0.7.tar.gz.md5 \
-        apache-forrest-0.7-RC1.tar.gz
-        md5sum apache-forrest-0.7-RC1.tar.gz]]>
-                    </source>
-                    <p>... output should match that of the md5 file.</p>
-                </li>
-                <li>
-                    <p>Create a maintenance branch in SVN</p>
-                    <ol>
-                        <li>
-                            <p>Open the command line</p>
-                        </li>
-                        <li>
-                            <p>Change to the root directory of the release candidate</p>
-                        </li>
-                        <li>
-                            <p>run <code>svn copy -m "Create the x.y release branch from r#####" \
-                                    https://svn.apache.org/repos/asf/forrest/trunk \
-                                    https://svn.apache.org/repos/asf/forrest/branches/forrest_xy_branch </code> where
-                                'xy' is a compact form of the version (e.g. 04, 041, 05) and 'r#####' is the SVN
-                                revision number that the branch was created from which was the revision that the release
-                                candidates were generated from.</p>
-                            <p> See <a href="http://svn.apache.org/repos/asf/forrest/branches/"
-                                    >http://svn.apache.org/repos/asf/forrest/branches/</a> If someone has done a commit
-                                before you get to do it, then specify the revision number with -r </p>
-                            <fixme author="">What do I see at http://svn.apache.org/repos/asf/forrest/branches/ if s.o.
-                                has done a commit? What is this stuff revision numer with -r for?</fixme>
-                        </li>
-                    </ol>
-                </li>
-            </ol>
-        </section>
-
-        <section>
-            <title>Testing the release candidate</title>
-            <p>Test the actual distribution on various platforms.</p>
-            <ol>
-                <li>
-                    <p>Upload the release candidates and signatures to a committer's webspace. Use the .tar.gz from the
-                        UNIX machine and .zip from the Windows machine.</p>
-                </li>
-                <li>
-                    <p>Use template <a href="test_and_vote_on_rel_cand.txt">test_and_vote_on_rel_cand.txt</a> for an
-                        email to the dev-list asking all developers to test and vote.</p>
-                </li>
-                <li>
-                    <p>As the votes come in</p>
-                    <ul>
-                        <li>Make sure the distributions unpacks on different systems w/o problems.</li>
-                        <li>Make sure that somebody has followed the actual user instructions in the Forrest
-                            distribution at README.txt and index.html</li>
-                        <li>Encourage people to build ome difficult sites.</li>
-                    </ul>
-
-                </li>
-                <li>If necessarry start again with <a href="#BuildDist">Building the distribution</a> and build another
-                    release candidate.</li>
-                <li />
-            </ol>
-        </section>
-
-        <section id="FinalRel">
-            <title>Finalizing the Release</title>
-            <p>When a good release candidate has been achieved and affirmed by the vote, we'll finalize the release.</p>
-
-            <ol>
-                <li>
-                    <p>rename the Release Candidates distribution files apache-forrest-X.Y-RCx.tar.gz and
-                        apache-forrest-X.Y-RCx.zip to their final filenames apache-forrest-X.Y.tar.gz and
-                        apache-forrest-X.Y.zip</p>
-                </li>
-                <li>
-                    <p>Create new .md5 and .asc-files following the procedure in <a href="#signing">outlined
-                    above</a></p>
-                </li>
-                <li>
-                    <p>If there have been changes to the trunk since the branch was created, then merge trunk to branch.</p>
-                    <fixme author="fso">What is the purpose of this step? It doesn't seem to be right because trunk may
-                        already contain parts of the next version. What we should do is do all fixing of RC-problems in
-                        the rc-branch (same as changing docs) then, on release, merge branch back into trunk to
-                        integrate fixes and doc-changes back into trunk. wdyt?</fixme>
-                </li>
-                <li>
-                    <p>If everything looks okay tag SVN by running <code>svn copy -m "Create tag forrest_xy from release
-                            branch" \ https://svn.apache.org/repos/asf/forrest/branches/forrest_xy_branch \
-                            https://svn.apache.org/repos/asf/forrest/tags/forrest_xy</code> from the command line of
-                        your system, where 'xy' is a compact (without the dots) form of the version number (e.g. 04,
-                        041, 05).</p>
-                    <fixme author="fso">If we change procedure to create an rc-branch this will become a merge changes
-                        from trunk then rename rc-branch to final release branch. right?</fixme>
-                    <p>See <a href="http://svn.apache.org/repos/asf/forrest/tags/"
-                            >http://svn.apache.org/repos/asf/forrest/tags/</a> for more information.</p>
-                    <fixme author="fso">What if it doesn't, how do I tell, what do I do?</fixme>
-                </li>
-                <li>
-                    <p>Announce the end of the code-freeze by sendung the email-template <a
-                            href="announce_end_of_code_freeze.txt">announce_end_of_code_freeze.txt</a>to the dev
-                    list.</p>
-                </li>
-            </ol>
-        </section>
-
-        <section id="UploadAndAnnounce">
-            <title>Upload and announcement</title>
-            <p>In this phase we'll upload the new Release, wait for it to be available on most mirror sites, then
-                announce the new relase.</p>
-            <note>During this phase there is a lot of waiting. While things are happening you can be doing the <a
-                    href="Cleanups">Cleanups</a> described below.</note>
-            <ol>
-                <li>
-                    <p>Use scp to upload the release: the *.tar.gz, the *.zip, the *.asc and *.md5 files, and the
-                        RELEASE-NOTES-x.y.txt to people.apache.org at /www/www.apache.org/ dist/forrest/</p>
-                    <p>Ensure correct file permissions by executing <code>chgrp forrest *</code> then <code>chmod 664
-                        *</code> on the remote system.</p>
-                    <p>Each PMC member has a server account and belongs to the forrest group.</p>
-                    <p>The process is documented at <a href="http://www.apache.org/~bodewig/mirror.html"
-                            >http://www.apache.org/~bodewig/mirror.html</a> and <a
-                            href="http://www.apache.org/dev/#releases">http://www.apache.org/dev/#releases</a></p>
-
-                    <p>Leave the previous dist there as well, until after the announcement.</p>
-
-                    <note>The other files there (HEAD.html README.html LICENSE.txt KEYS) are all automatically updated
-                        from the SVN:forrest/dist/ repository. </note>
-                    <fixme author="">FIXME: Add notes about the KEYS file in the "forrest-dist" SVN respository.</fixme>
-                </li>
-
-                <li>
-                    <p>If necessary, re-arrange stuff at the Archives site <a
-                            href="http://archive.apache.org/ at dist/forrest/">http://archive.apache.org/ at
-                            dist/forrest/</a></p>
-                    <p> You should not need to touch anything, the artifacts are automatically copied from the main
-                        /dist/forrest/</p>
-                    <fixme author="fso">Purpose of this site. What needs to be rearranges and how do I tell?</fixme>
-                </li>
-
-                <li>
-                    <p>Wait for the various mirrors to pick up the new files.</p>
-                    <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.</p>
-                    <p> See "Status of mirrors" <a href="http://www.apache.org/mirrors/"
-                        >http://www.apache.org/mirrors/</a></p>
-                    <p> Take note of the time that the eu.apache.org mirror is updated, then compare each "mirror age"
-                        to that.</p>
-                    <fixme author="fso">What do I compare it for?</fixme>
-                    <p> When you see that a good proportion of the mirrors have received the release, then update the
-                        website, then do the announcement.</p>
-                </li>
-                <li>To create a copy of current dev-docs for the next development phase, open the check-out of trunk
-                    (!) and run 'cd site-author/content/xdocs' and 'svn copy docs_0_70 docs_0_80' (Adjust version
-                    numbers as needed.</li>
-                <li>Open site.xml and add a copy of the most current versioned section (e.g. &lt;v0.80&gt;) above it.
-                    Increment the first decimal of the sections name to reflect the next planned release (e.g. &lt;v0.90&gt;).
-                </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>
-                    <fixme author="fso">Need to go through .htaccess and clean up.</fixme>
-                </li>
-               
-                <li>
-                    <p>Rebuild (Forrest site) and publish the Forrest website as normal. Be sure to use the new version
-                        for building the docs. Refer to <a href="site:howToPublishDocs">Publishing Forrest
-                            Documentation</a> for details.</p>
-                </li>
-                <li>
-                    <p>Update the xml.apache.org website
-                        Edit xml-site/src/documentation/content/xdocs/news.xml and record the
-                        announcement, and then commit the new HTML to xml-site/targets/forrest
-                        Note that they use forrest-0.6 to build their website.
-                        See http://xml.apache.org/guidelines.html#website-top</p>
-                    <fixme author="fso">Can sbdy pls explain the purpose of this step?</fixme>
-                    <p>Remember that there is currently an rsync delay for all ASF websites.
-                        <a href="http://www.apache.org/dev/project-site.html">http://www.apache.org/dev/project-site.html</a></p>
-                    <fixme author="fso">Meaning?</fixme>
-                </li>
-                <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'.</p>
-                    <p>See previous announcements for examples:</p>
-                    <ul>
-                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=103746673310573">0.2</a></li>
-                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=104399934113331">0.3 </a></li>
-                        <li><a href="http://marc.theaimsgroup.com/?l=jakarta-announce&amp;m=104510734501302">0.4</a></li>
-                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=106352706005681">0.5</a></li>
-                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=106541447606765">0.5.1</a></li>
-                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=109784461425740">0.6</a></li>
-                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=111960678028211">0.7</a></li>
-                    </ul>
-                </li>
-                <li><p>Do the Freshmeat announcement:
-                    <a href="http://freshmeat.net/projects/forrest/">http://freshmeat.net/projects/forrest/</a></p></li>
-            </ol>
-
-        </section>
-
-        <section id="cleanup">
-            <title>Cleanup</title>
-            <ol>
-                <li><p>Edit main/build.xml, increment the version and add a -dev tag:
-                    around line 45:
-                    <![CDATA[<property name="version" value="0.8-dev"/>]]></p></li>
-                <li><p>Edit main/forrest.build.xml and update the version:
-                    around line 32:</p>
-                    <source><![CDATA[
-    <property name="version" value="0.8-dev"/>  
-
-    around line 52:
-    <description>
-    |                 Forrest Site Builder                  |
-    |                        0.8-dev                             |
-                        ]]></source>
-                </li>
-                <li><p>Remove old dist files from the /www/www.apache.org/dist/forrest/ directory.
-                    They have already been archived at archive.apache.org/dist/forrest/</p></li>
-                <li><p>Do some Jira administration (need to be in the jira-administrators group)</p>
-                <fixme author="fso">Does it make sense to pass this job to the Jira-role?</fixme>
-                    <ol>
-                        <li><p>Tweak the "release" versions via "admin" interface at our Jira. Do this ...</p></li>
-                        <li><p>Re-name the VersionIds using "Manage Versions" then "Edit details":
-                            e.g. 0.7-dev is renamed to 0.7 and 0.8 becomes 0.8-dev</p></li>
-                        <li><p>Mark 0.7 as released using "Manage Versions".</p></li>
-                        <li><p>Review the Issues for the old version and move any Incomplete ones up.</p></li>
-                        <li><p>Change the "fixfor" attribute to the next verion for the
-                            "project.issues-rss-url" RSS feed in forrest.properties</p></li>
-                    </ol>
-                    
-                </li>
-                <li><p>Cleanup this RELEASE_PROCESS.txt file to set version number examples
-                    to be ready for the next release.</p>
-                    <fixme author="fso">I'd like to drop this step and rather word everything more flexibly.</fixme>
-                </li>
-                <li><p>Remove the release candidates from your public_html directory.</p></li>
-            </ol>
-            
-        </section>
-        
-        <section id="conclusion">
-            <title>Conclusion</title>
-            <p>All done!</p>
-            <p>Or perhaps not.. if you think of anything, please refine these instructions.</p>
-        </section>
-        
-        
-    </body>
-</document>
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+  Copyright 2006 The Apache Software Foundation or its licensors,
+  as applicable.
+
+  Licensed under the Apache License, Version 2.0 (the "License");
+  you may not use this file except in compliance with the License.
+  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+-->
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+  "http://forrest.apache.org/dtd/document-v20.dtd">
+<document>
+    <header>
+        <title>How to Release Forrest</title>
+        <abstract>This documents the steps that the Release Manager (RM) should follow when doing a Forrest
+        release.</abstract>
+    </header>
+    <body>
+
+        <section id="About">
+            <title>About this Document</title>
+            <p>This documents the steps that the Release Manager (RM) should follow when doing a Forrest release. Note
+                that it might have mistakes - we seem to discover something new each time and some steps might need to
+                happen in a different order. Fine tune these notes for next time. Do some practice runs.</p>
+
+            <p>There are some steps that other committers, and even developers, can assist with, especially in the areas
+                of getting ready for the release and the final testing. Many of the steps can be done only by the
+                Release Manager.</p>
+
+            <p>It is not the Release Manager's job to fix bugs nor address blocker issues. The RM job begins when the
+                project is ready to do the release.</p>
+        </section>
+
+        <section id="PrepProject">
+            <title>Preparing the Project for the release</title>
+            <ol>
+                <li>
+                    <p>The Release Manager (RM) starts the process to finalise the outstanding blocker issues. </p>
+                    <p>Check and make sure the following preconditions are met:</p>
+                    <ul>
+                        <li>
+                            <p>Has the project prepared or updated the Roadmap to schedule the realistic Issues?</p>
+                        </li>
+                        <li>
+                            <p>Has the project made good progress towards fixing the Blockers and applying the
+                                outstanding patches?</p>
+                        </li>
+                    </ul>
+                    <p>If not, then the project is not yet ready for release. Remember that it
+                      is not the RM's job to do this.</p>
+                    <p>If so, then send an email to get the project to decide what to do with the remaining issues. Propose to
+                        delay some issues to a future release, encourage people to fix others. See <a
+                            href="http://issues.apache.org/jira/browse/FOR-853">FOR-853</a>. Look at <a
+                            href="http://www.mail-archive.com/dev@forrest.apache.org/msg02310.html">msg02310.html</a>
+                        for an example of such a message.</p>
+
+                </li>
+                <li>
+                    <p>Start discussion on Java-Version to use for compiling and testing the release.</p>
+                </li>
+            </ol>
+        </section>
+
+        <section id="PrepTeam">
+            <title>Preparations for the Release Team</title>
+            <p>Particularly the Release Manager, but also anyone assisting, needs to be familiar
+              with standard procedures and Apache terminology. This is crucial for a successful release.</p>
+            <ol>
+                <li>
+                    <p>If you have never done a release before or need to refresh your memory, read all about Apache
+                        Releases in general at <a href="http://www.apache.org/dev/#releases"
+                            >http://www.apache.org/dev/#releases</a>. Make sure any assistants have read and understood
+                        this as well.</p>
+                </li>
+                <li>
+                    <p>Make sure every team member is familiar with the process of signing releases and generating MD5
+                        and PGP. You'll find some more info 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>
+                </li>
+                <li>
+                    <p>Ensure that as many PMC members as possible have their PGP keys in the KEYS file in Forrest's
+                        root directory. Instructions on how to add keys are included in that file. Instructions on how to
+                        create and manage pgp-keys can be found at the abovementioned references.</p>
+                </li>
+                <li>
+                    <p>Make sure every team member has downloaded and installed the Java-Version to use for compiling
+                        the release. Downloading and installing that version should be done well ahead of time to avoid
+                        delays.</p>
+                </li>
+
+            </ol>
+        </section>
+
+        <section id="PrepRelPlan">
+            <title>Prepare the Release Plan</title>
+            <p>Prepare the Release Plan to define the corner stones of the coming release</p>
+            <ol>
+                <li>Java-Version to test this release</li>
+                <li>Start of code-freeze</li>
+                <li>Start of test-period</li>
+                <li>Vote on release candidate</li>
+                <li>Optional creation of release candidate #2 (when there are bugs)</li>
+                <li>Start of test-period #2</li>
+                <li>Vote on release candidate #2</li>
+                <li>Scheduled release Date</li>
+            </ol>
+
+            <p>Use the email template <a href="propose_release_plan.txt">propose_release_plan.txt</a> to write and
+                propose your plan, then call for a quick vote on the release plan on the dev list.</p>
+            <note>There are various reasons for voting on the Release Plan, e.g. makes people aware that a code-freeze
+                is about to happen; encourage them to get involved with the release; ensure that the date is suitable
+                and people will be around to test and then vote on the actual release. See a good discussion <a
+                    href="http://marc.theaimsgroup.com/?t=114296877800003">in the archives</a>
+            </note>
+        </section>
+
+        <section id="PrepCodeBase">
+            <title>Preparing the Code Base</title>
+            <ol>
+                <li>
+                    <p>Ensure that there are no copyright issues. The committers and PMC would have been continually
+                        monitoring this. There are some tools to assist with scanning for issues, e.g. <a
+                            href="svn:committers/relicense/src/perl/relicense.txt"
+                            >svn:committers/relicense/src/perl/relicense.txt</a> and <a href="svn:committers/tools/"
+                            >svn:committers/tools/</a>
+                    </p>
+                </li>
+                <li>
+                    <p>Ensure that the line-endings and svn:eol-style property are correct for all files. See <a
+                            href="svn:committers/tools/">svn:committers/tools/</a></p>
+                </li>
+                <li>
+                    <p>Ensure that documentation is ready.</p>
+                </li>
+                <li>
+                    <p>Ensure that all relevant plugins have been deployed to plugins/0.8-dev/ See other notes at
+                        plugins/RELEASE_PROCESS.txt</p>
+                    <fixme author="fso">Check and integrate plugins/RELEASE_PROCESS.txt as a new document.</fixme>
+                </li>
+            </ol>
+        </section>
+
+        <section id="PrepNewBranch">
+            <title>Prepare Release Branch</title>
+
+            <fixme author="fso">We need to discuss order from here on. My idea is to adjust docs before we enter code
+                freeze to save time later. But if the rc fails and release is postponed might need to roll back changes
+                easily and - if possible - roll them forward later. So creating an svn branch for the rc seems to make
+                sense to me. Also: For more than one person working on building the release for different OS it would
+                also be good to have all the changes in svn committed already rather than doing it later. Probably
+                easiest would be to create an rc branch here and co that. I'd sacrifice the alternative approach for
+                that which is far too risky for my liking anyway. wdyt?</fixme>
+
+            <p>In this step you check out a fresh copy from SVN to make sure you have no local modifications, especially
+                those that might be hidden by svn:ignore settings. It will soon become the release branch.</p>
+            <note>This step is actually just preparation to keep code-freeze period as short as possible.</note>
+<fixme author="dc"> What does that mean?</fixme>
+            <ol>
+                <li>
+                    <p>Create a new empty directory 'Forrest_Release' on your system and make it the current
+                    directory.</p>
+                </li>
+                <li>
+                    <p>Start <code>svn co https://svn.apache.org/repos/asf/forrest/trunk</code> from the command-line of
+                        your system or the equivalent for the svn-tool you use.</p>
+                </li>
+            </ol>
+
+            <note>This will take quite a while if you are on a dial-up connection. See alternatives below.</note>
+
+            <p>Alternative Approach</p>
+
+            <ol>
+                <li> Do 'svn update -r HEAD' to ensure that you are up-to-date. </li>
+                <li> Run 'svn status --no-ignore' </li>
+                <li>
+                    <p>Delete any extra files you might have added/changed in your local copy. <strong>They must not be
+                            packed with the release.</strong> It must be a pristine copy of the current trunk.</p>
+                </li>
+            </ol>
+            <warning>This approach requires a good understanding of svn and how it works. It is not as automatic and
+                safe as the method above.</warning>
+        </section>
+
+        <section id="adjustDocs">
+            <title>Prepare Docs for next release cycle</title>
+
+            <fixme author="">I'd suggest the following steps to keep build size small and simplify procedure:</fixme>
+
+
+            <ol>
+                <li>
+                    <p>Edit version subtabs in site.xml as follows:</p>
+
+                    <ol>
+                        <li>
+                            <p>Move all version numbers one line down so that </p>
+                            <source>
+                                <![CDATA[
+ <versions tab="docs">
+    <overview label="Overview" href="versions/index.html"/>
+    <v0.8 label="0.8-dev" href="site:v0.80//index"/>
+    <v0.7 label="0.7 (current)" href="site:v0.70//index"/>
+    <v0.6 label="0.6" href="site:v0.60//index"/>
+  </versions>
+                        ]]>
+                            </source>
+                            <p>becomes</p>
+                            <source>
+                                <![CDATA[
+ <versions tab="docs">
+    <overview label="Overview" href="versions/index.html"/>
+    <v0.9 label="0.9-dev" href="site:v0.90//index"/>
+    <v0.8 label="0.8 (current)" href="site:v0.80//index"/>
+    <v0.7 label="0.7" href="site:v0.70//index"/>
+  </versions>
+                        ]]></source>
+                        </li>
+                    </ol>
+                </li>
+                <li>
+                    <p>Remove past versions (0.6) docs-directory from svn branch.</p>
+                    <fixme author="fso">find and list svn-command</fixme>
+
+                </li>
+                <li>
+                    <p>Adjust version-numbers in site.xml.</p>
+                    <fixme author="fso">This used to be 'Do global replace throughout docs_0_80 to replace the string
+                        ="site:v0.70 with ="site:v0.80' but this needs checking.</fixme>
+                    
+                </li>
+                
+
+
+
+                <li>
+                    <p>Edit site-author/status.xml:</p>
+                    <ol>
+                        <li>
+                            <p>Remove the -dev from the current &lt;release&gt; tag, and set the release
+                            date.</p>
+                        </li>
+                        <li>
+                            <p>Add a new &lt;release&gt; for development on the next version e.g. from:
+                                &lt;release version=&quot;0.7-dev&quot; date=&quot;not yet
+                                released&quot;&gt; ... to: &lt;release version=&quot;0.8-dev&quot;
+                                date=&quot;not yet released&quot;&gt; &lt;/release&gt;
+                                &lt;release version=&quot;0.7&quot;
+                                date=&quot;2002-02-13&quot;&gt; ...</p>
+                        </li>
+                    </ol>
+
+
+                </li>
+                <li>
+                    <p>Edit the forrest/site-author/content/xdocs/mirrors.html and adjust all version-specific content.</p>
+                    <fixme author="">FIXME: There is a bug (FOR-300) in the forrest build which generates to
+                        main/site/mirrors.html instead of build/site/mirrors.html</fixme>
+                </li>
+                <li>
+                    <p>Edit the Forrest home page in the "News and events" section and add a text like:</p>
+                    <source> Apache Forrest 0.xx was released on [Date]. [Important new features] </source>
+                </li>
+                <li>
+                    <p> Rename the deployed plugins directory by issuing the following commands at the command line </p>
+                    <source> cd /svn/asf/forrest-site svn up svn mv plugins/0.8-dev plugins/0.8 svn mkdir
+                        plugins/0.9-dev svn commit</source>
+                    <fixme author="fso">Issue them where and to what end?</fixme>
+                </li>
+                
+
+            </ol>
+        </section>
+
+        <section id="BuildDist">
+            <title>Building the distribution</title>
+            <p>In this phase you build the release candidate to be tested.</p>
+            <note>You can practice the following steps (as far as creating the branch) without committing anything even
+                before code-freeze. This ensures a good release candidate.</note>
+            <ol>
+                <li>Use template <a href="anounce_code_freeze.txt">anounce_code_freeze.txt</a> to send a reminder-mail
+                    to dev-list when the code-freeze commences.</li>
+                <li>
+                    <p>Update your release checkout (svn up) to include last minute changes.</p>
+                </li>
+                <li> </li>
+                <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 <code>build test</code>. 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>
+                    <note>It is not your job to fix bugs and code freeze should not commence with a broken trunk.</note>
+                    <p>If there are bugs 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 <code>svn st --no-ignore</code> 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>
+                    <ul>
+                        <li>
+                            <p>Edit main/build.xml and replace the '-dev' text with '' i.e. nothing: around line 45:
+                                &lt;property name=&quot;forrest.version&quot;
+                                value=&quot;0.7-dev&quot;/&gt; to: &lt;property
+                                name=&quot;forrest.version&quot; value=&quot;0.7&quot;/&gt; </p>
+                        </li>
+
+                        <li>
+                            <p>Edit main/forrest.build.xml to update the version tag to remove "-dev". There are two
+                                occurences: around line 32: &lt;property name=&quot;forrest.version&quot;
+                                value=&quot;0.7-dev&quot;/&gt; ^^^^ around line 60:
+                                &lt;description&gt; | Forrest Site Builder | | 0.7-dev | ^^^^</p>
+                        </li>
+                        <li>
+                            <p>Edit plugins/build.xml and increase the docs version number to the next major release:
+                                around line 23: &lt;property name=&quot;forrest.version&quot;
+                                value=&quot;0.7&quot;/&gt; to: &lt;property
+                                name=&quot;forrest.version&quot; value=&quot;0.8&quot;/&gt; </p>
+                            <note>This is deliberately a major version up. It is assumed that plugins will be developed
+                                against the next version of Forrest. Individual plugins can override this property in
+                                their own build files.</note>
+                        </li>
+                    </ul>
+
+                </li>
+                <li>
+                    <p>Ensure that each plugin that uses the locationmap has its "release version" set to 0.8 or
+                    more.</p>
+                </li>
+                <li>
+                    <p>Edit 4 files in tools/forrestbar to update the version number to match the new release: -
+                        install.rdf, line 24: &lt;em:version&gt;0.7&lt;/em:version&gt; - install.js,
+                        line 19: var err = initInstall("ForrestBar", "forrestbar", "0.7"); -
+                        xpi/chrome/content/contents.rdf, line 27: chrome:displayName="ForrestBar 0.7"/> -
+                        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: &lt;menuitem label=&quot;Current
+                        Docs (0.7)&quot;
+                        onclick=&quot;navigate(&apos;http://forrest.apache.org/docs_0_70/index.html&apos;);&quot;
+                        /&gt; </p>
+                    <fixme author="">There are probably other areas which have version numbers. How can we improve this?</fixme>
+
+                    <fixme author="">Not sure at what stage we get rid of the old docs, e.g. 0.6</fixme>
+                    <fixme author="">Not sure at what stage need to edit site-author/content/xdocs/mirrors.html (Presume
+                        that it should be done after packing release. See below.)</fixme>
+
+                </li>
+                <li>
+                    <p>Create a new file, etc/RELEASE-NOTES-x.y.txt, where x.y is the version currently being released.
+                        It is best to copy an earlier RELEASE-NOTES file, to keep a common layout. In this file, provide
+                        a summary of changes, and check for general accuracy. Scan the status.xml/changes and the
+                        Roadmap via the issues tracker, to find the important issues. </p>
+                </li>
+                <li>
+                    <p>Set your Java version to be the lowest specified of our supported versions.</p>
+                    <note> Set the environment variable JAVA_HOME to the path of the Java version. Note for Windows: If
+                        you change the setting in system properties, you need to logout and login again for the changes
+                        to become effective.</note>
+                </li>
+                <li>
+                    <p>Take note of the SVN revision number of your trunk by running <code>svn info</code> from the
+                        command line in the Release Candidates root dir and look at the "Last Changed Rev: ######".</p>
+                    <fixme author="">What is this used for?</fixme>
+                </li>
+                <li>
+                    <p>Now we will build the release candidates for Windows and Unix.</p>
+                    <note>The reason for creating two separate archives is the line-endings dilemma between Windows and
+                        UNIX. SVN ensures correct line-endings on each operating system (as long as committers have been
+                        diligent when adding/updating the repository).</note>
+                    <ul>
+                        <li>
+                            <p>On a UNIX machine:<br /> Change to directory main and run <code>build release-dist</code>
+                                to generate the distributions on a UNIX machine.</p>
+                            <p> Two archives are created: apache-forrest-X.Y.tar.gz apache-forrest-X.Y.zip. Ignore the
+                                *.zip archive.</p>
+                            <p>Unpack and test the relevant archive in a fresh new directory.</p>
+                        </li>
+                        <li>
+                            <p>On a Windows machine:<br /> Change to directory main and run <code>build
+                                release-dist</code> to generate the distributions on a UNIX machine.</p>
+                            <p> Two archives are created: apache-forrest-X.Y.tar.gz apache-forrest-X.Y.zip. Ignore the
+                                *.tar.gz archive.</p>
+                            <p>Unpack and test the relevant archive in a fresh new directory.</p>
+                        </li>
+
+                    </ul>
+                </li>
+                <li>
+                    <p id="signing">Sign the Release Candidates distribution file and the *.asc and *.md5 files.</p>
+                    <p>Here is one example when using <a href="http://www.gnupg.org/(en)/download/index.html">gpg</a>
+                        and openssl from the command line. </p>
+                    <note>An windows version for openssl can be found at <a
+                            href="http://www.slproweb.com/products/Win32OpenSSL.html"
+                            >http://www.slproweb.com/products/Win32OpenSSL.html</a></note>
+                    <source><![CDATA[
+        gpg --recv-key <myKey>
+        gpg --output crossley-apache-forrest-0.7-RC1.tar.gz.asc \
+        --detach-sig --armor apache-forrest-0.7-RC1.tar.gz
+        gpg --verify crossley-apache-forrest-0.7.tar.gz.asc \
+        apache-forrest-0.7-RC1.tar.gz]]></source>
+                    <p> ... should say "Good signature from ..."</p>
+
+                    <source><![CDATA[
+        openssl dgst -md5 -out apache-forrest-0.7.tar.gz.md5 \
+        apache-forrest-0.7-RC1.tar.gz
+        md5sum apache-forrest-0.7-RC1.tar.gz]]>
+                    </source>
+                    <p>... output should match that of the md5 file.</p>
+                </li>
+                <li>
+                    <p>Create a maintenance branch in SVN</p>
+                    <ol>
+                        <li>
+                            <p>Open the command line</p>
+                        </li>
+                        <li>
+                            <p>Change to the root directory of the release candidate</p>
+                        </li>
+                        <li>
+                            <p>run <code>svn copy -m "Create the x.y release branch from r#####" \
+                                    https://svn.apache.org/repos/asf/forrest/trunk \
+                                    https://svn.apache.org/repos/asf/forrest/branches/forrest_xy_branch </code> where
+                                'xy' is a compact form of the version (e.g. 04, 041, 05) and 'r#####' is the SVN
+                                revision number that the branch was created from which was the revision that the release
+                                candidates were generated from.</p>
+                            <p> See <a href="http://svn.apache.org/repos/asf/forrest/branches/"
+                                    >http://svn.apache.org/repos/asf/forrest/branches/</a> If someone has done a commit
+                                before you get to do it, then specify the revision number with -r </p>
+                            <fixme author="">What do I see at http://svn.apache.org/repos/asf/forrest/branches/ if s.o.
+                                has done a commit? What is this stuff revision numer with -r for?</fixme>
+                        </li>
+                    </ol>
+                </li>
+            </ol>
+        </section>
+
+        <section>
+            <title>Testing the release candidate</title>
+            <p>Test the actual distribution on various platforms.</p>
+            <ol>
+                <li>
+                    <p>Upload the release candidates and signatures to a committer's webspace. Use the .tar.gz from the
+                        UNIX machine and .zip from the Windows machine.</p>
+                </li>
+                <li>
+                    <p>Use template <a href="test_and_vote_on_rel_cand.txt">test_and_vote_on_rel_cand.txt</a> for an
+                        email to the dev-list asking all developers to test and vote.</p>
+                </li>
+                <li>
+                    <p>As the votes come in</p>
+                    <ul>
+                        <li>Make sure the distributions unpacks on different systems w/o problems.</li>
+                        <li>Make sure that somebody has followed the actual user instructions in the Forrest
+                            distribution at README.txt and index.html</li>
+                        <li>Encourage people to build ome difficult sites.</li>
+                    </ul>
+
+                </li>
+                <li>If necessarry start again with <a href="#BuildDist">Building the distribution</a> and build another
+                    release candidate.</li>
+                <li />
+            </ol>
+        </section>
+
+        <section id="FinalRel">
+            <title>Finalizing the Release</title>
+            <p>When a good release candidate has been achieved and affirmed by the vote, we'll finalize the release.</p>
+
+            <ol>
+                <li>
+                    <p>rename the Release Candidates distribution files apache-forrest-X.Y-RCx.tar.gz and
+                        apache-forrest-X.Y-RCx.zip to their final filenames apache-forrest-X.Y.tar.gz and
+                        apache-forrest-X.Y.zip</p>
+                </li>
+                <li>
+                    <p>Create new .md5 and .asc-files following the procedure in <a href="#signing">outlined
+                    above</a></p>
+                </li>
+                <li>
+                    <p>If there have been changes to the trunk since the branch was created, then merge trunk to branch.</p>
+                    <fixme author="fso">What is the purpose of this step? It doesn't seem to be right because trunk may
+                        already contain parts of the next version. What we should do is do all fixing of RC-problems in
+                        the rc-branch (same as changing docs) then, on release, merge branch back into trunk to
+                        integrate fixes and doc-changes back into trunk. wdyt?</fixme>
+                </li>
+                <li>
+                    <p>If everything looks okay tag SVN by running <code>svn copy -m "Create tag forrest_xy from release
+                            branch" \ https://svn.apache.org/repos/asf/forrest/branches/forrest_xy_branch \
+                            https://svn.apache.org/repos/asf/forrest/tags/forrest_xy</code> from the command line of
+                        your system, where 'xy' is a compact (without the dots) form of the version number (e.g. 04,
+                        041, 05).</p>
+                    <fixme author="fso">If we change procedure to create an rc-branch this will become a merge changes
+                        from trunk then rename rc-branch to final release branch. right?</fixme>
+                    <p>See <a href="http://svn.apache.org/repos/asf/forrest/tags/"
+                            >http://svn.apache.org/repos/asf/forrest/tags/</a> for more information.</p>
+                    <fixme author="fso">What if it doesn't, how do I tell, what do I do?</fixme>
+                </li>
+                <li>
+                    <p>Announce the end of the code-freeze by sendung the email-template <a
+                            href="announce_end_of_code_freeze.txt">announce_end_of_code_freeze.txt</a>to the dev
+                    list.</p>
+                </li>
+            </ol>
+        </section>
+
+        <section id="UploadAndAnnounce">
+            <title>Upload and announcement</title>
+            <p>In this phase we'll upload the new Release, wait for it to be available on most mirror sites, then
+                announce the new relase.</p>
+            <note>During this phase there is a lot of waiting. While things are happening you can be doing the <a
+                    href="Cleanups">Cleanups</a> described below.</note>
+            <ol>
+                <li>
+                    <p>Use scp to upload the release: the *.tar.gz, the *.zip, the *.asc and *.md5 files, and the
+                        RELEASE-NOTES-x.y.txt to people.apache.org at /www/www.apache.org/ dist/forrest/</p>
+                    <p>Ensure correct file permissions by executing <code>chgrp forrest *</code> then <code>chmod 664
+                        *</code> on the remote system.</p>
+                    <p>Each PMC member has a server account and belongs to the forrest group.</p>
+                    <p>The process is documented at <a href="http://www.apache.org/~bodewig/mirror.html"
+                            >http://www.apache.org/~bodewig/mirror.html</a> and <a
+                            href="http://www.apache.org/dev/#releases">http://www.apache.org/dev/#releases</a></p>
+
+                    <p>Leave the previous dist there as well, until after the announcement.</p>
+
+                    <note>The other files there (HEAD.html README.html LICENSE.txt KEYS) are all automatically updated
+                        from the SVN:forrest/dist/ repository. </note>
+                    <fixme author="">FIXME: Add notes about the KEYS file in the "forrest-dist" SVN respository.</fixme>
+                </li>
+
+                <li>
+                    <p>If necessary, re-arrange stuff at the Archives site <a
+                            href="http://archive.apache.org/ at dist/forrest/">http://archive.apache.org/ at
+                            dist/forrest/</a></p>
+                    <p> You should not need to touch anything, the artifacts are automatically copied from the main
+                        /dist/forrest/</p>
+                    <fixme author="fso">Purpose of this site. What needs to be rearranges and how do I tell?</fixme>
+                </li>
+
+                <li>
+                    <p>Wait for the various mirrors to pick up the new files.</p>
+                    <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.</p>
+                    <p> See "Status of mirrors" <a href="http://www.apache.org/mirrors/"
+                        >http://www.apache.org/mirrors/</a></p>
+                    <p> Take note of the time that the eu.apache.org mirror is updated, then compare each "mirror age"
+                        to that.</p>
+                    <fixme author="fso">What do I compare it for?</fixme>
+                    <p> When you see that a good proportion of the mirrors have received the release, then update the
+                        website, then do the announcement.</p>
+                </li>
+                <li>To create a copy of current dev-docs for the next development phase, open the check-out of trunk
+                    (!) and run 'cd site-author/content/xdocs' and 'svn copy docs_0_70 docs_0_80' (Adjust version
+                    numbers as needed.</li>
+                <li>Open site.xml and add a copy of the most current versioned section (e.g. &lt;v0.80&gt;) above it.
+                    Increment the first decimal of the sections name to reflect the next planned release (e.g. &lt;v0.90&gt;).
+                </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>
+                    <fixme author="fso">Need to go through .htaccess and clean up.</fixme>
+                </li>
+               
+                <li>
+                    <p>Rebuild (Forrest site) and publish the Forrest website as normal. Be sure to use the new version
+                        for building the docs. Refer to <a href="site:howToPublishDocs">Publishing Forrest
+                            Documentation</a> for details.</p>
+                </li>
+                <li>
+                    <p>Update the xml.apache.org website
+                        Edit xml-site/src/documentation/content/xdocs/news.xml and record the
+                        announcement, and then commit the new HTML to xml-site/targets/forrest
+                        Note that they use forrest-0.6 to build their website.
+                        See http://xml.apache.org/guidelines.html#website-top</p>
+                    <fixme author="fso">Can sbdy pls explain the purpose of this step?</fixme>
+                    <p>Remember that there is currently an rsync delay for all ASF websites.
+                        <a href="http://www.apache.org/dev/project-site.html">http://www.apache.org/dev/project-site.html</a></p>
+                    <fixme author="fso">Meaning?</fixme>
+                </li>
+                <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'.</p>
+                    <p>See previous announcements for examples:</p>
+                    <ul>
+                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=103746673310573">0.2</a></li>
+                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=104399934113331">0.3 </a></li>
+                        <li><a href="http://marc.theaimsgroup.com/?l=jakarta-announce&amp;m=104510734501302">0.4</a></li>
+                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=106352706005681">0.5</a></li>
+                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=106541447606765">0.5.1</a></li>
+                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=109784461425740">0.6</a></li>
+                        <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&amp;m=111960678028211">0.7</a></li>
+                    </ul>
+                </li>
+                <li><p>Do the Freshmeat announcement:
+                    <a href="http://freshmeat.net/projects/forrest/">http://freshmeat.net/projects/forrest/</a></p></li>
+            </ol>
+
+        </section>
+
+        <section id="cleanup">
+            <title>Cleanup</title>
+            <ol>
+                <li><p>Edit main/build.xml, increment the version and add a -dev tag:
+                    around line 45:
+                    <![CDATA[<property name="version" value="0.8-dev"/>]]></p></li>
+                <li><p>Edit main/forrest.build.xml and update the version:
+                    around line 32:</p>
+                    <source><![CDATA[
+    <property name="version" value="0.8-dev"/>  
+
+    around line 52:
+    <description>
+    |                 Forrest Site Builder                  |
+    |                        0.8-dev                             |
+                        ]]></source>
+                </li>
+                <li><p>Remove old dist files from the /www/www.apache.org/dist/forrest/ directory.
+                    They have already been archived at archive.apache.org/dist/forrest/</p></li>
+                <li><p>Do some Jira administration (need to be in the jira-administrators group)</p>
+                <fixme author="fso">Does it make sense to pass this job to the Jira-role?</fixme>
+                    <ol>
+                        <li><p>Tweak the "release" versions via "admin" interface at our Jira. Do this ...</p></li>
+                        <li><p>Re-name the VersionIds using "Manage Versions" then "Edit details":
+                            e.g. 0.7-dev is renamed to 0.7 and 0.8 becomes 0.8-dev</p></li>
+                        <li><p>Mark 0.7 as released using "Manage Versions".</p></li>
+                        <li><p>Review the Issues for the old version and move any Incomplete ones up.</p></li>
+                        <li><p>Change the "fixfor" attribute to the next verion for the
+                            "project.issues-rss-url" RSS feed in forrest.properties</p></li>
+                    </ol>
+                    
+                </li>
+                <li><p>Cleanup this RELEASE_PROCESS.txt file to set version number examples
+                    to be ready for the next release.</p>
+                    <fixme author="fso">I'd like to drop this step and rather word everything more flexibly.</fixme>
+                </li>
+                <li><p>Remove the release candidates from your public_html directory.</p></li>
+            </ol>
+            
+        </section>
+        
+        <section id="conclusion">
+            <title>Conclusion</title>
+            <p>All done!</p>
+            <p>Or perhaps not.. if you think of anything, please refine these instructions.</p>
+        </section>
+        
+        
+    </body>
+</document>

Propchange: forrest/trunk/site-author/content/xdocs/procedures/release/How_to_release.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Modified: forrest/trunk/site-author/content/xdocs/procedures/release/announce_end_of_code_freeze.txt
URL: http://svn.apache.org/viewvc/forrest/trunk/site-author/content/xdocs/procedures/release/announce_end_of_code_freeze.txt?rev=408800&r1=408799&r2=408800&view=diff
==============================================================================
--- forrest/trunk/site-author/content/xdocs/procedures/release/announce_end_of_code_freeze.txt (original)
+++ forrest/trunk/site-author/content/xdocs/procedures/release/announce_end_of_code_freeze.txt Mon May 22 17:32:08 2006
@@ -1,4 +1,4 @@
-Subject: [Important] End of code-freeze
-
-The code-freeze has endet.
-
+Subject: [Important] End of code-freeze
+
+The code-freeze has endet.
+

Propchange: forrest/trunk/site-author/content/xdocs/procedures/release/announce_end_of_code_freeze.txt
------------------------------------------------------------------------------
    svn:eol-style = native

Modified: forrest/trunk/site-author/content/xdocs/procedures/release/announce_release.txt
URL: http://svn.apache.org/viewvc/forrest/trunk/site-author/content/xdocs/procedures/release/announce_release.txt?rev=408800&r1=408799&r2=408800&view=diff
==============================================================================
--- forrest/trunk/site-author/content/xdocs/procedures/release/announce_release.txt (original)
+++ forrest/trunk/site-author/content/xdocs/procedures/release/announce_release.txt Mon May 22 17:32:08 2006
@@ -1,8 +1,8 @@
-To: dev@forrest.apache.org,user@forrest.apache.org,announce@apache.org,announcements@xml.apache.org
-Subject: [Announce] Apache Forrest X.Y.Z
-
-     !! Always refer them to the mirror facility
-     !! Never mention the URL www.apache.org/ dist/ in email or web pages.
-   Use the template at etc/announcement.txt
-   Use your spelling checker!
+To: dev@forrest.apache.org,user@forrest.apache.org,announce@apache.org,announcements@xml.apache.org
+Subject: [Announce] Apache Forrest X.Y.Z
+
+     !! Always refer them to the mirror facility
+     !! Never mention the URL www.apache.org/ dist/ in email or web pages.
+   Use the template at etc/announcement.txt
+   Use your spelling checker!
    Sign the email (e.g. GPG) if possible.

Propchange: forrest/trunk/site-author/content/xdocs/procedures/release/announce_release.txt
------------------------------------------------------------------------------
    svn:eol-style = native

Modified: forrest/trunk/site-author/content/xdocs/procedures/release/anounce_code_freeze.txt
URL: http://svn.apache.org/viewvc/forrest/trunk/site-author/content/xdocs/procedures/release/anounce_code_freeze.txt?rev=408800&r1=408799&r2=408800&view=diff
==============================================================================
--- forrest/trunk/site-author/content/xdocs/procedures/release/anounce_code_freeze.txt (original)
+++ forrest/trunk/site-author/content/xdocs/procedures/release/anounce_code_freeze.txt Mon May 22 17:32:08 2006
@@ -1,35 +1,35 @@
-Subject: [Important] code-freeze commenced
-
-The code-freeze is now happening to allow us to pack the
-release candidates and make them available for testing.
-
-Code-freeze means *no* non-essential commits to the trunk
-or to the new release branch. Other branches are free to
-continue.
-
-There should be no code enhancements or new functionality,
-because that could introduce new bugs.
-
-The main aim is to find and fix important bugs. Any minor
-issues are delayed until after release (add to Jira).
-
-Documentation corrections can happen because they will not
-break anything. As long as we do test the documentation
-building just prior to making the final release candidate.
-
-However, if there are important code changes that are required
-you can make a proposal to allow that commit. The PMC will
-make a quick decision.
-
-Next important milestones are:
-
-* Create release candidate #2 if there have been changes
-  on [date]
-  [www.timeanddate.com-URL]
-
-* Actual release date is [date]
-  [www.timeanddate.com-URL]
-
-Now we will go and build the releases which might take
-some time. The next message will tell you where to get
+Subject: [Important] code-freeze commenced
+
+The code-freeze is now happening to allow us to pack the
+release candidates and make them available for testing.
+
+Code-freeze means *no* non-essential commits to the trunk
+or to the new release branch. Other branches are free to
+continue.
+
+There should be no code enhancements or new functionality,
+because that could introduce new bugs.
+
+The main aim is to find and fix important bugs. Any minor
+issues are delayed until after release (add to Jira).
+
+Documentation corrections can happen because they will not
+break anything. As long as we do test the documentation
+building just prior to making the final release candidate.
+
+However, if there are important code changes that are required
+you can make a proposal to allow that commit. The PMC will
+make a quick decision.
+
+Next important milestones are:
+
+* Create release candidate #2 if there have been changes
+  on [date]
+  [www.timeanddate.com-URL]
+
+* Actual release date is [date]
+  [www.timeanddate.com-URL]
+
+Now we will go and build the releases which might take
+some time. The next message will tell you where to get
 the release candidates and describe how to test.

Propchange: forrest/trunk/site-author/content/xdocs/procedures/release/anounce_code_freeze.txt
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message