You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by da...@cocoon.zones.apache.org on 2006/08/01 16:46:13 UTC
[DAISY] Created: Howto Release Cocoon
A new document has been created.
http://cocoon.zones.apache.org/daisy/documentation/1195.html
Document ID: 1195
Branch: main
Language: default
Name: Howto Release Cocoon
Document Type: Cocoon Document
Created: 8/1/06 2:45:51 PM
Creator (owner): Helma van der Linden
State: publish
Parts
=====
Content
-------
Mime type: text/xml
Size: 11142 bytes
Content:
<html>
<body>
<h1>Overview</h1>
<p>This info is for Cocoon committers who need to distribute a new release of
Cocoon or any subproject of Cocoon.</p>
<h1>Naming Conventions</h1>
<p>The name of each downloadable archive should be named after the following
regular expression:</p>
<pre>cocoon(-SUBPROJECT)?-VERSION(-VARIANT)?-(src|bin).(zip|tar.gz) </pre>
<p>Where:</p>
<ul>
<li>SUBPROJECT is the name of the eventual subproject (optional)</li>
<li>VERSION is a version string without dashes (ex. 2.1.5, 2.2m1...)</li>
<li>VARIANT identifies the "type of distribution" (ex. win32, jdk12, linux,
jdk14...) (optional)</li>
</ul>
<p>So, all our archives shall be called something like:
<em>cocoon-2.0.4-jdk14-bin.tar.gz</em> or <em>cocoon-2.1m1-src.zip</em> and so
on...</p>
<p>Subprojects apply to the same rule, except that of course they add their
project name before the version information. For example for Lenya, the name
should be along the lines of <em>cocoon-lenya-1.0-bin.tar.gz</em>.</p>
<h1>The Release Process</h1>
<p>This is a step-by-step procedure that covers the last eight days before the
actual release date.</p>
<h1>Code Freeze</h1>
<p>Prior to the release day, a code freeze should be announced approx. eight
days in advance.</p>
<h1>Test Phase</h1>
<p>During the code freeze the whole Cocoon community is invited to test test
distribution, find and fix bugs and update the documentation. if desired an
invitation to the community to help in polishing the release can be send out to
the mailing lists.</p>
<h1>Voting the release tarball</h1>
<p>Three days before the actual release date, a release tarball is generated and
put on a publically reachable location. Now a vote is started for the next 72h
if this tarball can be used as the final release. This tarball only differs in
the version information.</p>
<p>During this period, no commits should alter the repository.</p>
<p>If the vote is accepted, the release process is started. If the vote fails,
it has to be decided what to do next.</p>
<h1>Starting the Release Process</h1>
<p>Send a simple mail to the developer list. This is in order to ensure that
noone will check in during the release process. If someone checks in during the
building, testing and tagging, the release process has to be started at the
beginning again. Otherwise the release version is not the one tagged in
Subversion.</p>
<h1>Get the Version</h1>
<p>Check-out a fresh copy from Subversion on a unix platform (this is important,
do not use windows!)</p>
<h1>Set Correct Version Information</h1>
<p>Change the version information in
<em>src/java/org/apache/cocoon/cocoon.properties</em> by removing <em>-dev</em>
and eventually add new release information like m1, b1 etc. If this release is a
final version, change the <em>released.version</em> info to the new version as
well.</p>
<p>And also change the version accordingly in <em>forrest.properties</em>. But
don't check-in this yet!</p>
<h1>Exclude unstable blocks from the default build</h1>
<p>Edit the blocks.properties file and exclude all unstable blocks. Since it's a
release they should not get compiled by default.</p>
<h1>Build the Distrubtion</h1>
<p>Make sure that you make a clean build and that you are really not using
windows:</p>
<pre># ./build.sh clean-dist
# ./build.sh dist
</pre>
<h1>Test the distribution</h1>
<p>Unarchive the build distribution and test it. These tests should include
different platforms (windows and unix) and different JDKs (1.3 and 1.4). Testing
includes building Cocoon from the release version and trying out the samples.
Please also run 'build test'.</p>
<h1>Decide what to do next</h1>
<p>If any problem occurs during building and/or testing, you have to decide
whether this is a blocker and has to be fixed or if this problem can be ignored.
If it is a blocker, the problem must be fixed and after that you have to restart
at the beginning. This decision is a from case to case decision and it's the
release manager who decides if it's a blocker or not :)</p>
<h1>Continuing the Release Process</h1>
<p>Now check-in the changed version from the first step and tag the release in
Subversion. Currently three files should have been changed in the last steps:
</p>
<ul>
<li><em>src/java/org/apache/cocoon/cocoon.properties</em> : Version information
</li>
<li><em>forrest.properties</em> : Version information</li>
<li><em>blocks.properties</em> : Disable unstable blocks</li>
</ul>
<p>Use RELEASE_{VERSION} as the tag for tagging the release, like RELEASE_2_1_5.
</p>
<h1>Starting the Next Version</h1>
<p>Change the version in <em>src/java/org/apache/cocoon/cocoon.properties</em>
by increasing the version information and adding "-dev" at the end, for example
2.1m3-dev.</p>
<p>Change the version in <em>forrest.properties</em> to the same value.</p>
<p>Update the <em>blocks.properties</em> and enable all blocks that you have
disabled for the release.</p>
<p>Change <em>status.xml</em> by adding the release with proper version and date
and start a new release section with placeholders. Add a dummy action here.</p>
<p>Check-in all these changes.</p>
<h1>Signing the Release</h1>
<p>Therefore you have to put your public key in the KEYS file (before the
starting the release process!). In addition create a md5 file for the
distribution</p>
<h1>Bugtracking</h1>
<p>Enter the new version into JIRA, so users can file entries against it.</p>
<h1>Uploading the Release</h1>
<p>The only (ONLY) place where distributions shall reside is inside the
<em>/www/www.apache.org/dist/cocoon</em> on <em>www.apache.org</em>.</p>
<p>This directory contains three subdirectories:</p>
<ul>
<li>BINARIES: this is where the binary distribution tar/zipballs are located.
</li>
<li>SOURCES: this is where the source distribution tar/zipballs are located.
</li>
<li>OLD: all old and deprecated distributions.</li>
</ul>
<p>Upload the release (including signatures and MD5 files) to
<em>www.apache.org</em> and put it under
<em>/www/www.apache.org/dist/cocoon</em> into the correct directories (SOURCES
and BINARIES). Make sure that you set the permissions correctly. It's important
to give the group write access!</p>
<p>Add/change the links from the cocoon directory to the new version in the
sources/binaries directory. Update the README.html and the HEADER.html. For more
information see below.</p>
<p>In the future, when other subprojects of Cocoon will start putting out their
own releases, new directories will be created under the top level directory,
with the same structure. For example the final directory will look something
like:</p>
<pre>www/www.apache.org/dist/cocoon/
|
+- BINARIES/
| |
| +- cocoon-2.0.3-bin.tar.gz
| |
| \- cocoon-2.0.4-bin.tar.gz
|
+- SOURCES/
| |
| +- cocoon-2.0.3-src.tar.gz
| |
| +- cocoon-2.0.4-src.tar.gz
| |
| +- cocoon-2.1m1-src.tar.gz
| |
| \- cocoon-2.1m2-src.tar.gz
|
+- OLD/
| |
| +- cocoon-1.8.1.tar.gz
| |
| \- cocoon-1.8.2.tar.gz
|
+- cocoon-latest-bin.tar.gz -> BINARIES/cocoon-2.0.4-bin.tar.gz
|
+- cocoon-latest-src.tar.gz -> SOURCES/cocoon-2.0.4-src.tar.gz
|
+- lenya/
| |
| +- BINARIES/
| | |
| | \- cocoon-lenya-1.0-bin.tar.gz
| |
| +- SOURCES/
| | |
| | \- cocoon-lenya-1.0-src.tar.gz
| |
| +- cocoon-lenya-latest-bin.tar.gz -> BINARIES/cocoon-lenya-1.0-bin.tar.gz
| |
| \- cocoon-lenya-latest-src.tar.gz -> SOURCES/cocoon-lenya-1.0-src.tar.gz
|
\- license.txt
</pre>
<h1>Announcement</h1>
<p>Announce to the developer list that the release process is finished and end a
possible code freeze.</p>
<h1>Take a break...</h1>
<p>Now wait for 24h so the mirror sites can pick up the new version. You can
have a look at <a href="http://www.apache.org/mirrors/">mirror info page</a> to
see the status of the mirrors.</p>
<h1>Update mirror page</h1>
<p>Change the mirror.html in the cocoon-site module as well and update this
single file on the website. For more information see below.</p>
<h1>Create the announcement mail</h1>
<p>Currently this is hand-typed (or copied) - we have to reinstall the
announcement target. Send this email to wherever appropriate. Currently it goes
to (dev at cocoon.apache.org, users at cocoon.apache.org, general at
xml.apache.org and announcements at xml.apache.org)</p>
<p>Remember that the locations to mention in any announcements when downloads
are involved is <em>http://cocoon.apache.org/mirror.cgi</em>. So that people
will actually __use__ the mirrors and not peg the Foundation's bandwidth (which
is quite expensive).</p>
<h1>Register final version</h1>
<p>Enter a final version (no betas or milestones) into Freshmeat.</p>
<h1>Update the site docs</h1>
<p>Update the site docs as described
<a href="http://wiki.apache.org/cocoon/CocoonWebsiteUpdate">here</a>.</p>
<h1>Enter new version</h1>
<p>Update the latest version on the
<a href="http://wiki.apache.org/cocoon/LatestRelease">Wiki</a>.</p>
<h1>Publishing and linking</h1>
<p>Once the distribution ball is rolled following the naming convention and
copied in the appropriate directory as outlined above, make sure that the
following links are present (and only those links) in the root directory for the
project/subproject:</p>
<ul>
<li>A link to the latest released stable version for each tar/zipball: for
example, if the latest release is 2.0.4, and this release includes 3 different
balls, 2 for binaries and 1 for sources, the following links must be done:</li>
</ul>
<pre> # cd /www/www.apache.org/dist/cocoon
# ln -s BINARIES/cocoon-2.0.4-vm14-bin.tar.gz cocoon-2.0.4-vm14-bin.tar.gz
# ln -s BINARIES/cocoon-2.0.4-vm14-bin.zip cocoon-2.0.4-vm14-bin.zip
# ln -s BINARIES/cocoon-2.0.4-bin.tar.gz cocoon-2.0.4-bin.tar.gz
# ln -s BINARIES/cocoon-2.0.4-bin.zip cocoon-2.0.4-bin.zip
# ln -s SOURCES/cocoon-2.0.4-src.tar.gz cocoon-2.0.4-src.tar.gz
# ln -s SOURCES/cocoon-2.0.4-src.zip cocoon-2.0.4-src.zip
</pre>
<ul>
<li>A link to the latest milestone version for each tar/zipball (if present):
for example, if 2.1m1 publishes only one ball, the source one:</li>
</ul>
<pre> # cd /www/www.apache.org/dist/cocoon
# ln -s SOURCES/cocoon-2.1-src.tar.gz cocoon-2.1-src.tar.gz
# ln -s SOURCES/cocoon-2.1-src.zip cocoon-2.1-src.zip
</pre>
<ul>
<li>A link to the LATEST STABLE DOWNLOADABLE with the "version" string replaced
by the "latest" keyword. If the above example of 2.0.4 is still valid:</li>
</ul>
<pre> # cd /www/www.apache.org/dist/cocoon
# ln -s BINARIES/ccoon-2.0.4-vm14-bin.tar.gz cocoon-latest-vm14-bin.tar.gz
# ln -s BINARIES/cocoon-2.0.4-vm14-bin.zip cocoon-latest-vm14-bin.zip
# ln -s BINARIES/cocoon-2.0.4-bin.tar.gz cocoon-latest-bin.tar.gz
# ln -s BINARIES/cocoon-2.0.4-bin.zip cocoon-latest-bin.zip
# ln -s SOURCES/cocoon-2.0.4-src.tar.gz cocoon-latest-src.tar.gz
# ln -s SOURCES/cocoon-2.0.4-src.zip cocoon-latest-src.zip
</pre>
<p>Make sure to change the "latest version" strings and URLs in the README.html
and HEADER.html files in the /www/www.apache.org/dist/cocoon/ directory and the
mirror.html file in the /www/cocoon.apache.org/ directory.</p>
</body>
</html>
Collections
===========
The document belongs to the following collections: generaldocs