Author: hwright
Date: Tue Jun 28 21:24:36 2011
New Revision: 1140853
URL: http://svn.apache.org/viewvc?rev=1140853&view=rev
Log:
* publish/docs/community-guide/releasing.part.html
(before-release, rolling-release): Put in the right order inside the release
instructions.
Modified:
subversion/site/publish/docs/community-guide/releasing.part.html
Modified: subversion/site/publish/docs/community-guide/releasing.part.html
URL:
http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/releasing.part.html?rev=1140853&r1=1140852&r2=1140853&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/releasing.part.html (original)
+++ subversion/site/publish/docs/community-guide/releasing.part.html Tue Jun 28
21:24:36 2011
@@ -640,6 +640,185 @@ voting, are always kept on the main rele
title="Link to this section">¶</a>
</h2>
+<div class="h3" id="before-release">
+<h3>Preparing to roll a release
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#before-release"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>So, a release branch has stabilized, and you are gearing up to roll
+the release. Before you can actually roll the archives, you need to
+set up a white-room rolling environment. This environment must
+contain pristine versions of some build tools.</p>
+
+<p>You need to grab vanilla source tarballs of the following build
+tools before proceeding:</p>
+
+<ul>
+<li><p><b>Autoconf</b> 2.59 (2.60 is a significant compatibility break
+from the 2.5x series, and is known to break APR)</p></li>
+<li><p><b>Libtool</b> 1.5.22</p></li>
+<li><p><b>SWIG</b> 1.3.25</p></li>
+</ul>
+
+<p>It is important that you do not use distribution shipped versions
+of this software as they are often patched in ways that are not
+portable. The version numbers given above should normally be
+reconsidered and increased to the latest stable upstream release in
+the time leading up to an A.B.0 release. Changing the version within
+an A.B.x series should only be done with careful considereration.</p>
+
+<p><b>Autoconf, Libtool and SWIG</b>: Pick a directory to contain your
+special build tools for Subversion RM duties - for example
+<tt>/opt/svnrm</tt>. Configure, build and install the three pieces of
+software with <tt>--prefix=/opt/svnrm</tt>, and remember, whenever you
+run <tt>dist.sh</tt> to be sure that <tt>/opt/svnrm/bin</tt> is at the
+front of your <tt>PATH</tt>.</p>
+
+<p>You can do all of the forgoing with the <tt>build-env</tt> subcommand
+of <tt>release.py</tt>.</p>
+
+</div> <!-- before-release -->
+
+<div class="h3" id="rolling-release">
+<h3>Rolling a release
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#rolling-release"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>Before rolling, first make sure that the latest version of the
+<tt>CHANGES</tt> file from trunk is merged into the release branch, and that
+the date at the top of <tt>CHANGES</tt> matches the planned release date of
+the tarball.</p>
+
+<p><b>Build the tarballs</b>: From within your Unix dependency
+directory, run:</p>
+<pre>
+PATH="/opt/svnrm/bin:$PATH" ./dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z
+</pre>
+<p>Watch <tt>dist.sh</tt>'s output to make sure everything goes
+smoothly; when it's done, you'll have tarballs in the cwd.</p>
+
+<p><b>Build the zipfiles</b>: From within your Win32 dependency
+directory, run:</p>
+<pre>
+PATH="/opt/svnrm/bin:$PATH" ./dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z -zip
+</pre>
+<p>Watch <tt>dist.sh</tt>'s output to make sure everything goes
+smoothly; when it's done, you'll have zipfiles in the cwd.</p>
+
+<p>Test one or both of the tarballs:</p>
+
+<pre>
+ a) tar zxvf subversion-X.Y.Z.tar.gz; cd subversion-X.Y.Z
+ b) ./configure
+
+ See INSTALL, section III.B for detailed instructions on
+ configuring/building Subversion.
+
+ If you installed Apache in some place other than the default, as
+ mentioned above, you will need to use the same
+ --prefix=/usr/local/apache2 option as used to configure Apache.
+
+ You may also want to use --enable-mod-activation, which will
+ automatically enable the required Subversion modules in the
+ Apache config file.
+
+ c) make
+ d) make check
+ e) make install (this activates mod_dav)
+ f) make davcheck
+
+ For this, start up Apache after having configured according to
+ the directions in subversion/tests/cmdline/README.
+
+ Make sure, that if you maintain a development installation of
+ apache, that you check the config file and update it for the
+ new release area where you're testing the tar-ball.
+
+ (Unless you rename the tree which gets extracted from the
+ tarball to match what's in httpd.conf, you will need to edit
+ httpd.conf)
+
+ g) make svncheck
+
+ First, start up svnserve with these args:
+
+ $ subversion/svnserve/svnserve -d -r \
+ `pwd`/subversion/tests/cmdline
+
+ -d tells svnserve to run as a daemon
+ -r tells svnserve to use the following directory as the
+ logical file system root directory.
+
+ After svnserve is running as a daemon 'make svncheck' should run
+
+ h) Then test that you can check out the Subversion repository
+ with this environment:
+
+ subversion/svn/svn co
https://svn.apache.org/repos/asf/subversion/trunk
+
+ i) Verify that the perl and python swig bindings at least compile.
+ If you can't do this, then have another developer verify.
+
+ (see bindings/swig/INSTALL for details)
+
+ Ensure that ./configure detected a suitable version of swig,
+ perl, and python. Then:
+
+ make swig-py
+ make check-swig-py
+ sudo make install-swig-py
+
+ make swig-pl
+ make check-swig-pl
+ sudo make install-swig-pl
+
+ j) Verify that the javahl bindings at least compile.
+ If you can't do this, then have another developer verify.
+
+ (see bindings/java/javahl/README for details)
+
+ Ensure that ./configure detected a suitable jdk, and then
+ possibly re-run with '--enable-javahl' and '--with-jdk=':
+
+ make javahl
+ sudo make install-javahl
+ make check-javahl
+</pre>
+
+<p><b>Use GnuPG to sign release:</b></p>
+<pre>
+ gpg -ba subversion-X.Y.Z.tar.bz2
+ gpg -ba subversion-X.Y.Z.tar.gz
+ gpg -ba subversion-X.Y.Z.zip
+</pre>
+
+<p><b>Subversion Operations</b></p>
+<p>Create the tag with the <tt>svn_version.h</tt> that reflects the final
+release. You do this by updating your working copy to the release
+revision, 1234 in the example below. Run svnversion to verify that
+you do not have a mixed working copy or modified working copy, i.e.
+svnversion outputs only the release revision (not 1234:1235 or 1234M).
+Then place the <tt>svn_version.h.dist</tt> file in place in the working copy
+and copy from the working copy to the tag URL. For example:</p>
+
+<pre>
+ svn up -r 1234
+ svnversion .
+ cp svn_version.h.dist subversion/include/svn_version.h
+ svn cp . ^/subversion/tags/X.Y.Z \
+ -m "Tagging release X.Y.Z with svn_version.h matching tarball"
+</pre>
+
+<p>Note: Please always make a tag, even for release candidates.</p>
+
+<p>Bump the <tt>svn_version.h</tt> for the original branch. If you just did
+1.0.2 then <tt>svn_version.h</tt> should have the proper values for 1.0.3 and
+so on.</p>
+
+</div> <!-- rolling-release -->
+
<div class="h3" id="tarball-signing">
<h3>Signing source distribution packages (a.k.a tarballs)
<a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#tarball-signing"
@@ -822,186 +1001,6 @@ [email protected].</p>
</div> <!-- releasing-release -->
-<div class="h3" id="before-release">
-<h3>Preparing to roll a release
- <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#before-release"
- title="Link to this section">¶</a>
-</h3>
-
-<p>So, a release branch has stabilized, and you are gearing up to roll
-the release. Before you can actually roll the archives, you need to
-set up a white-room rolling environment. This environment must
-contain pristine versions of some build tools.</p>
-
-<p>You need to grab vanilla source tarballs of the following build
-tools before proceeding:</p>
-
-<ul>
-<li><p><b>Autoconf</b> 2.59 (2.60 is a significant compatibility break
-from the 2.5x series, and is known to break APR)</p></li>
-<li><p><b>Libtool</b> 1.5.22</p></li>
-<li><p><b>SWIG</b> 1.3.25</p></li>
-</ul>
-
-<p>It is important that you do not use distribution shipped versions
-of this software as they are often patched in ways that are not
-portable. The version numbers given above should normally be
-reconsidered and increased to the latest stable upstream release in
-the time leading up to an A.B.0 release. Changing the version within
-an A.B.x series should only be done with careful considereration.</p>
-
-<p><b>Autoconf, Libtool and SWIG</b>: Pick a directory to contain your
-special build tools for Subversion RM duties - for example
-<tt>/opt/svnrm</tt>. Configure, build and install the three pieces of
-software with <tt>--prefix=/opt/svnrm</tt>, and remember, whenever you
-run <tt>dist.sh</tt> to be sure that <tt>/opt/svnrm/bin</tt> is at the
-front of your <tt>PATH</tt>.</p>
-
-<p>You can do all of the forgoing with the <tt>build-env</tt> subcommand
-of <tt>release.py</tt>.</p>
-
-</div> <!-- before-release -->
-
-
-<div class="h3" id="rolling-release">
-<h3>Rolling a release
- <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#rolling-release"
- title="Link to this section">¶</a>
-</h3>
-
-<p>Before rolling, first make sure that the latest version of the
-<tt>CHANGES</tt> file from trunk is merged into the release branch, and that
-the date at the top of <tt>CHANGES</tt> matches the planned release date of
-the tarball.</p>
-
-<p><b>Build the tarballs</b>: From within your Unix dependency
-directory, run:</p>
-<pre>
-PATH="/opt/svnrm/bin:$PATH" ./dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z
-</pre>
-<p>Watch <tt>dist.sh</tt>'s output to make sure everything goes
-smoothly; when it's done, you'll have tarballs in the cwd.</p>
-
-<p><b>Build the zipfiles</b>: From within your Win32 dependency
-directory, run:</p>
-<pre>
-PATH="/opt/svnrm/bin:$PATH" ./dist.sh -v X.Y.Z -r 1234 -pr branches/X.Y.Z -zip
-</pre>
-<p>Watch <tt>dist.sh</tt>'s output to make sure everything goes
-smoothly; when it's done, you'll have zipfiles in the cwd.</p>
-
-<p>Test one or both of the tarballs:</p>
-
-<pre>
- a) tar zxvf subversion-X.Y.Z.tar.gz; cd subversion-X.Y.Z
- b) ./configure
-
- See INSTALL, section III.B for detailed instructions on
- configuring/building Subversion.
-
- If you installed Apache in some place other than the default, as
- mentioned above, you will need to use the same
- --prefix=/usr/local/apache2 option as used to configure Apache.
-
- You may also want to use --enable-mod-activation, which will
- automatically enable the required Subversion modules in the
- Apache config file.
-
- c) make
- d) make check
- e) make install (this activates mod_dav)
- f) make davcheck
-
- For this, start up Apache after having configured according to
- the directions in subversion/tests/cmdline/README.
-
- Make sure, that if you maintain a development installation of
- apache, that you check the config file and update it for the
- new release area where you're testing the tar-ball.
-
- (Unless you rename the tree which gets extracted from the
- tarball to match what's in httpd.conf, you will need to edit
- httpd.conf)
-
- g) make svncheck
-
- First, start up svnserve with these args:
-
- $ subversion/svnserve/svnserve -d -r \
- `pwd`/subversion/tests/cmdline
-
- -d tells svnserve to run as a daemon
- -r tells svnserve to use the following directory as the
- logical file system root directory.
-
- After svnserve is running as a daemon 'make svncheck' should run
-
- h) Then test that you can check out the Subversion repository
- with this environment:
-
- subversion/svn/svn co
https://svn.apache.org/repos/asf/subversion/trunk
-
- i) Verify that the perl and python swig bindings at least compile.
- If you can't do this, then have another developer verify.
-
- (see bindings/swig/INSTALL for details)
-
- Ensure that ./configure detected a suitable version of swig,
- perl, and python. Then:
-
- make swig-py
- make check-swig-py
- sudo make install-swig-py
-
- make swig-pl
- make check-swig-pl
- sudo make install-swig-pl
-
- j) Verify that the javahl bindings at least compile.
- If you can't do this, then have another developer verify.
-
- (see bindings/java/javahl/README for details)
-
- Ensure that ./configure detected a suitable jdk, and then
- possibly re-run with '--enable-javahl' and '--with-jdk=':
-
- make javahl
- sudo make install-javahl
- make check-javahl
-</pre>
-
-<p><b>Use GnuPG to sign release:</b></p>
-<pre>
- gpg -ba subversion-X.Y.Z.tar.bz2
- gpg -ba subversion-X.Y.Z.tar.gz
- gpg -ba subversion-X.Y.Z.zip
-</pre>
-
-<p><b>Subversion Operations</b></p>
-<p>Create the tag with the <tt>svn_version.h</tt> that reflects the final
-release. You do this by updating your working copy to the release
-revision, 1234 in the example below. Run svnversion to verify that
-you do not have a mixed working copy or modified working copy, i.e.
-svnversion outputs only the release revision (not 1234:1235 or 1234M).
-Then place the <tt>svn_version.h.dist</tt> file in place in the working copy
-and copy from the working copy to the tag URL. For example:</p>
-
-<pre>
- svn up -r 1234
- svnversion .
- cp svn_version.h.dist subversion/include/svn_version.h
- svn cp . ^/subversion/tags/X.Y.Z \
- -m "Tagging release X.Y.Z with svn_version.h matching tarball"
-</pre>
-
-<p>Note: Please always make a tag, even for release candidates.</p>
-
-<p>Bump the <tt>svn_version.h</tt> for the original branch. If you just did
-1.0.2 then <tt>svn_version.h</tt> should have the proper values for 1.0.3 and
-so on.</p>
-
-</div> <!-- rolling-release -->
-
</div> <!-- release-creating -->
