cziegeler 2004/06/08 03:54:50
Modified: src/documentation/content/xdocs/devinfo releasing.xml
Log:
Polishing
Revision Changes Path
1.2 +73 -48
cocoon-site/src/documentation/content/xdocs/devinfo/releasing.xml
Index: releasing.xml
===================================================================
RCS file:
/home/cvs/cocoon-site/src/documentation/content/xdocs/devinfo/releasing.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- releasing.xml 8 Jun 2004 08:20:43 -0000 1.1
+++ releasing.xml 8 Jun 2004 10:54:50 -0000 1.2
@@ -8,66 +8,78 @@
<section>
<title>Overview</title>
<p>
- This info is for Cocoon committers who need to distribute a new
release of Cocoon.
+ This info is for Cocoon committers who need to distribute a new
release of Cocoon
+ or any subproject of Cocoon.
</p>
</section>
<section>
- <title>A) Naming Conventions</title>
+ <title>Naming Conventions</title>
<p>
The name of each downloadable archive should be named after the
following
regular expression:
</p>
<source>
- PROJECT(-SUBPROJECT)?-VERSION(-VARIANT)?-(src|bin).(zip|tar.gz)
+ cocoon(-SUBPROJECT)?-VERSION(-VARIANT)?-(src|bin).(zip|tar.gz)
</source>
<p>
Where:
</p>
<ul>
- <li>PROJECT is the name of the top-level project,</li>
<li>SUBPROJECT is the name of the eventual subproject (optional)</li>
- <li>VERSION is a version string (without - dashes)</li>
+ <li>VERSION is a version string without dashes (ex. 2.1.5,
2.2m1...)</li>
<li>VARIANT identifies the "type of distribution" (ex. win32, jdk12,
linux, jdk14...) (optional)</li>
</ul>
<p>
- So, in Cocoon's case, all our archives shall be called something
like:
+ So, all our archives shall be called something like:
<em>cocoon-2.0.4-jdk14-bin.tar.gz</em> or
<em>cocoon-2.1m1-src.zip</em>
and so on...
</p>
<p>
- If one day we ever released some subproject code (for example
Lenya), the
+ Subprojects apply to the same rule, except that of course they add
their
+ project name before the version information. For example for Lenya,
the
name should be along the lines of
<em>cocoon-lenya-1.0-bin.tar.gz</em>.
- You get the point.
</p>
</section>
<section>
- <title>B) The Release Process</title>
+ <title>The Release Process</title>
<p>
This is a step-by-step procedure.
</p>
<section>
- <title>Code freeze</title>
+ <title>Code Freeze</title>
<p>
- Prior to the release day, a code freeze should be announced
approx. 7 days in advance.
+ Prior to the release day, a code freeze should be announced
approx.
+ seven days in advance.
</p>
</section>
<section>
- <title>Announce the release process</title>
+ <title>Test Phase</title>
<p>
- Send a simple mail to the dev list. This is in order to ensure
that
+ During the code freeze the whole Cocoon community is invited to
test
+ test distribution, find and fix bugs and update the documentation.
if
+ desired an invitation to the community to help in polishing the
release
+ can be send out to the mailing lists.
+ </p>
+ </section>
+ <section>
+ <title>Starting the Release Process</title>
+ <p>
+ Send a simple mail to the developer list. This is in order to
ensure that
noone will check in during the release process. If someone checks
in
during the building, testing and tagging, the release process has
to
- be started at the beginning again.
+ be started at the beginning again. Otherwise the release version is
+ not the one tagged in CVS.
</p>
</section>
- <section><title>Get the version</title>
+ <section>
+ <title>Get the Version</title>
<p>
Check-out a fresh copy from the cvs on a unix platform (this is
important,
do not use windows!)
</p>
</section>
<section>
- <title>Set correct version information</title>
+ <title>Set Correct Version Information</title>
<p>
Change the version information in
<em>src/java/org/apache/cocoon/cocoon.properties</em>
by removing <em>-dev</em> and eventually add new release
information like m1, b1 etc.
@@ -87,7 +99,7 @@
</p>
</section>
<section>
- <title>Build the distrubtion</title>
+ <title>Build the Distrubtion</title>
<p>
Make sure that you make a clean build and that you are really not
using windows:
</p>
@@ -116,25 +128,45 @@
</p>
</section>
<section>
- <title>Continue with the release</title>
+ <title>Continuing the Release Process</title>
<p>
Now check-in the changed version from the first step and tag the
release in cvs.
+ Currently three files should have been changed in the last steps:
</p>
+ <ul>
+ <li><em>src/java/org/apache/cocoon/cocoon.properties</em> :
Version information</li>
+ <li><em>forrest.properties</em> : Version information</li>
+ <li><em>blocks.properties</em> : Disable unstable blocks</li>
+ </ul>
</section>
<section>
- <title>Start next version</title>
+ <title>Starting the Next Version</title>
+ <p>
+ Change the version in
<em>src/java/org/apache/cocoon/cocoon.properties</em>
+ by increasing the version information and adding "-dev" at the
end,
+ for example 2.1m3-dev.
+ </p>
+ <p>
+ Change the version in <em>forrest.properties</em> to the same
value.
+ </p>
<p>
- Check the version in
<em>src/java/org/apache/cocoon/cocoon.properties</em> by increasing
- the version information and adding "-dev" at the end, for example
m3-dev.
- Change status.xml by adding the release with proper version and
date and start a
- new release section with the placeholders. Add a dummy action here.
- And also change the version in forrest.properties
+ Update the <em>blocks.properties</em> and enable all blocks that
you have
+ disabled for the release.
+ </p>
+ <p>
+ Change <em>status.xml</em> by adding the release with proper
version
+ and date and start a new release section with placeholders. Add a
dummy
+ action here.
+ </p>
+ <p>
+ Check-in all these changes.
</p>
</section>
<section>
- <title>Sign the release</title>
+ <title>Signing the Release</title>
<p>
- Therefore you have to put your public key in the KEYS file before!
+ Therefore you have to put your public key in the KEYS file (before
the
+ starting the release process!).
In addition create a md5 file for the distribution
</p>
</section>
@@ -145,12 +177,14 @@
</p>
</section>
<section>
- <title>Upload the release</title>
+ <title>Uploading the Release</title>
<p>
- Upload the release and the signatures to www.apache.org and put it
- under /www/www.apache.org/dist/cocoon into the correct directories
(sources
- and binaries). Make sure that you set the permissions correctly.
+ Upload the release and the signatures to <em>www.apache.org</em>
and put it
+ under <em>/www/www.apache.org/dist/cocoon</em> into the correct
directories
+ (sources and binaries). Make sure that you set the permissions
correctly.
It's important to give the group write access!
+ </p>
+ <p>
Add/change the links from the cocoon directory to the new version
in
the sources/binaries directory. Update the README.html and the
HEADER.html.
For more information see below.
@@ -159,8 +193,8 @@
<section>
<title>Announcement</title>
<p>
- Announce to the dev list that the release process is finished and
end a possible
- code freeze.
+ Announce to the developer list that the release process is
finished
+ and end a possible code freeze.
</p>
</section>
<section>
@@ -186,6 +220,12 @@
Currently it goes to (dev at cocoon.apache.org, users at
cocoon.apache.org,
general at xml.apache.org and announcements at xml.apache.org)
</p>
+ <p>
+ Remember that the locations to mention in any announcements when
downloads
+ are involved is <em>http://cocoon.apache.org/mirror.cgi</em>.
+ So that people will actually __use__ the mirrors and not peg the
Foundation's
+ bandwidth (which is quite expensive).
+ </p>
</section>
<section>
<title>Register final version</title>
@@ -206,7 +246,7 @@
</section>
</section>
<section>
- <title>C) Directories</title>
+ <title>Directories</title>
<p>
The only (ONLY) place where distributions shall reside is inside the
/www/www.apache.org/dist/cocoon on daedalus.apache.org.
@@ -325,21 +365,6 @@
<p>
Note that for release final downloads you shouldn't edit the mirrors.html
file, as the release should always be linked to cocoon-latest-.....
- </p>
- </section>
- <section>
- <title>D) Mirroring and announcing</title>
- <p>
-Once the release is published wait at least 24 hours before announcing it to
-the mailing lists, so that mirror sites will have the opportunity to pick
-the changes up and you won't get bugged by people unable to download the
-distributions.
- </p>
- <p>
-Remember that the locations to mention in any announcements when downloads
-are involved is <em>http://cocoon.apache.org/mirror.cgi</em>.
-So that people will actually __use__ the mirrors and not peg the Foundation's
-bandwidth (which is quite expensive).
</p>
</section>
</body>
