You are viewing a plain text version of this content. The canonical link for it is here.
Posted to svn@forrest.apache.org by cr...@apache.org on 2006/05/23 02:32:09 UTC
svn commit: r408800 [1/2] -
/forrest/trunk/site-author/content/xdocs/procedures/release/
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 <release> tag, and set the release
- date.</p>
- </li>
- <li>
- <p>Add a new <release> for development on the next version e.g. from:
- <release version="0.7-dev" date="not yet
- released"> ... to: <release version="0.8-dev"
- date="not yet released"> </release>
- <release version="0.7"
- date="2002-02-13"> ...</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:
- <property name="forrest.version"
- value="0.7-dev"/> to: <property
- name="forrest.version" value="0.7"/> </p>
- </li>
-
- <li>
- <p>Edit main/forrest.build.xml to update the version tag to remove "-dev". There are two
- occurences: around line 32: <property name="forrest.version"
- value="0.7-dev"/> ^^^^ around line 60:
- <description> | 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: <property name="forrest.version"
- value="0.7"/> to: <property
- name="forrest.version" value="0.8"/> </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: <em:version>0.7</em:version> - 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: <menuitem label="Current
- Docs (0.7)"
- onclick="navigate('http://forrest.apache.org/docs_0_70/index.html');"
- /> </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. <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>
- <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&m=103746673310573">0.2</a></li>
- <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=104399934113331">0.3 </a></li>
- <li><a href="http://marc.theaimsgroup.com/?l=jakarta-announce&m=104510734501302">0.4</a></li>
- <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=106352706005681">0.5</a></li>
- <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=106541447606765">0.5.1</a></li>
- <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=109784461425740">0.6</a></li>
- <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&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 <release> tag, and set the release
+ date.</p>
+ </li>
+ <li>
+ <p>Add a new <release> for development on the next version e.g. from:
+ <release version="0.7-dev" date="not yet
+ released"> ... to: <release version="0.8-dev"
+ date="not yet released"> </release>
+ <release version="0.7"
+ date="2002-02-13"> ...</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:
+ <property name="forrest.version"
+ value="0.7-dev"/> to: <property
+ name="forrest.version" value="0.7"/> </p>
+ </li>
+
+ <li>
+ <p>Edit main/forrest.build.xml to update the version tag to remove "-dev". There are two
+ occurences: around line 32: <property name="forrest.version"
+ value="0.7-dev"/> ^^^^ around line 60:
+ <description> | 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: <property name="forrest.version"
+ value="0.7"/> to: <property
+ name="forrest.version" value="0.8"/> </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: <em:version>0.7</em:version> - 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: <menuitem label="Current
+ Docs (0.7)"
+ onclick="navigate('http://forrest.apache.org/docs_0_70/index.html');"
+ /> </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. <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>
+ <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&m=103746673310573">0.2</a></li>
+ <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=104399934113331">0.3 </a></li>
+ <li><a href="http://marc.theaimsgroup.com/?l=jakarta-announce&m=104510734501302">0.4</a></li>
+ <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=106352706005681">0.5</a></li>
+ <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=106541447606765">0.5.1</a></li>
+ <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&m=109784461425740">0.6</a></li>
+ <li><a href="http://marc.theaimsgroup.com/?l=xml-apache-announce&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
Re: [heads-up] please configure svn clients (Was: r408800 xdocs/procedures/release/)
Posted by David Crossley <cr...@apache.org>.
David Crossley wrote:
> Ferdinand Soethe wrote:
> >
> > (In the docs it says only: "However, you should still pay attention to the
> > messages from your svn client when you do 'svn commit'").
>
> Doing 'svn status' before doing the commit.
> http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.status.html
>
> With the command-line client, i do 'svn commit'
> which opens my editor for log message, it reports the
> files that have been changed in the same format as
> does 'svn status'.
>
> Properties are flagged in the second column. If there
> are none for new text files they you know its busted.
Erk, i just tried an example. It is the 'svn commit'
editor message that tells the property flag.
The message that goes to svn@forrest says
'Added myFile.txt (with props)"
...................^^^^^^^^^^
-David
> Text files should get the 'svn:eol-style native'
> property. Do 'svn proplist --verbose myFile.txt' to see.
>
> -David
Re: [heads-up] please configure svn clients (Was: r408800 xdocs/procedures/release/)
Posted by David Crossley <cr...@apache.org>.
Ferdinand Soethe wrote:
> David Crossley wrote:
>
> > Ferdinand, will you please configure your SVN client properly.
> > This causes too much unnecessary work for someone else,
> > usually me.
>
> > Please follow the instructions at:
> > http://www.apache.org/dev/version-control.html#https-svn
>
> Sorry David. I was unsure whether my current svn-client picked up the
> settings correctly so I figured if anything goes wrong I'll fix it
> when cleaning up.
>
> With these things please just throw them back at me instead of fixing
> them for me (if possible).
Better to fix it ASAP. Especially with new
files because people are more likely to review.
The result is mixed line-endings and poor patches.
> So how do you tell that something went wrong.
In this case, when i edited your document,
my editor reported that there were DOS line endings.
Usually i run a shell script which interrogates
our svn for the properties of each text file.
Another script searches for DOS carriage-returns.
I try to do this as often as possible but
unfortunately too long between.
> And what do I do to fix
> it apart from reconfiguring tortoise?
Use the command-line client :-) but still need
to configure it.
With most clients you can manually use 'svn propset'
before doing 'svn commit', but too tedious.
> (In the docs it says only: "However, you should still pay attention to the
> messages from your svn client when you do 'svn commit'").
Doing 'svn status' before doing the commit.
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.status.html
With the command-line client, i do 'svn commit'
which opens my editor for log message, it reports the
files that have been changed in the same format as
does 'svn status'.
Properties are flagged in the second column. If there
are none for new text files they you know its busted.
Text files should get the 'svn:eol-style native'
property. Do 'svn proplist --verbose myFile.txt' to see.
-David
Re: [heads-up] please configure svn clients (Was: r408800 xdocs/procedures/release/)
Posted by Ferdinand Soethe <fe...@apache.org>.
David Crossley wrote:
> Ferdinand, will you please configure your SVN client properly.
> This causes too much unnecessary work for someone else,
> usually me.
> Please follow the instructions at:
> http://www.apache.org/dev/version-control.html#https-svn
Sorry David. I was unsure whether my current svn-client picked up the
settings correctly so I figured if anything goes wrong I'll fix it
when cleaning up.
With these things please just throw them back at me instead of fixing
them for me (if possible).
So how do you tell that something went wrong. And what do I do to fix
it apart from reconfiguring tortoise? (In the docs it says only: "However, you should still pay attention to the
messages from your svn client when you do 'svn commit'").
--
Ferdinand Soethe
Re: [heads-up] please configure svn clients (Was: r408800 xdocs/procedures/release/)
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> David Crossley wrote:
> >Ferdinand, will you please configure your SVN client properly.
> >This causes too much unnecessary work for someone else,
> >usually me.
>
> Don't be modest - it's always you!
Until recently yes. Rick has been helping lately.
> The rest of us really do have a responsibility to help David keep SVN in
> good order. Having SVN clients configured properly is one small way, but
> we should also look for commits from people with incorrect settings and
> fix them before David wakes up.
It would take an eagle-eye to detect that from
the svn@ commit messages. See answer to Ferdinand
for more info.
> (nobody should feel like I am blaming them, I am as guilty as everyone
> else in leaving it to David and occasionally having a misconfigured client).
Me too. Thanks to XML there are often new filename
extensions.
-David
Re: [heads-up] please configure svn clients (Was: r408800 xdocs/procedures/release/)
Posted by Ross Gardler <rg...@apache.org>.
David Crossley wrote:
> Ferdinand, will you please configure your SVN client properly.
> This causes too much unnecessary work for someone else,
> usually me.
>
Don't be modest - it's always you!
The rest of us really do have a responsibility to help David keep SVN in
good order. Having SVN clients configured properly is one small way, but
we should also look for commits from people with incorrect settings and
fix them before David wakes up.
(nobody should feel like I am blaming them, I am as guilty as everyone
else in leaving it to David and occasionally having a misconfigured client).
Ross
[heads-up] please configure svn clients (Was: r408800 xdocs/procedures/release/)
Posted by David Crossley <cr...@apache.org>.
Ferdinand, will you please configure your SVN client properly.
This causes too much unnecessary work for someone else,
usually me.
Please follow the instructions at:
http://www.apache.org/dev/version-control.html#https-svn
-David
> 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)
--------------