Author: hwright
Date: Tue Jun 28 14:18:26 2011
New Revision: 1140634
URL: http://svn.apache.org/viewvc?rev=1140634&view=rev
Log:
Release docs: Move the section on Custom Releases into the greater
release-process section, and add a few words.
* publish/docs/community-guide/releasing.part.html
(custom-releases): Move to release-process, and make an h3. Add some text.
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=1140634&r1=1140633&r2=1140634&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/releasing.part.html (original)
+++ subversion/site/publish/docs/community-guide/releasing.part.html Tue Jun 28
14:18:26 2011
@@ -284,6 +284,54 @@ compatibility questions:</p>
</div> <!-- release-compat -->
+<div class="h3" id="custom-releases">
+<h3>Custom releases
+ <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#custom-releases"
+ title="Link to this section">¶</a>
+</h3>
+
+<p>Subversion does not distribute binary packages, but instead relies upon
+<a href="/packages.html">third-party packagers</a> to do so. Luckily, many
+individuals and companies have stepped in to volunteer their efforts in this
+regard, and we are grateful for their efforts.</p>
+
+<p>If you are a third-party packager, you may encounter instances when a bug
+fix or other change is important for your users, and you want to get it to
+them more quickly than the standard Subversion release cycle. Or you may
+maintain a set of patches locally which benefit your target audience.
+If possible, it is preferred to use the
+<a href="/docs/community-guide/general.html#patches">patch process</a> and
+have your changes accepted and applied to trunk to be released on the normal
+Subversion release schedule.</p>
+
+<p>However, if you feel that you need to make changes that would not be widely
+accepted by the Subversion developer community, or need to provide early
+access to unreleased features, you should follow the guidelines below. They
+are intended to help prevent confusion in the user community, and make both
+your distribution and the official Subversion releases as successful as
+possible.</p>
+
+<p>First, make sure you follow the <a
+href="http://www.apache.org/foundation/marks/";>ASF
+trademark policy</a>. You will need to differentiate your release
+from the standard Subversion releases to reduce any potential
+confusion caused by your custom release.</p>
+
+<p>Second, consider creating a branch in the public Subversion
+repository to track your changes and to potentially allow your custom
+changes to be merged into mainline Subversion.</p>
+
+<p>Third, if your custom release is likely to generate bug reports
+that would not be relevant to mainline Subversion, please stay in
+touch with the users of the custom release so you can intercept and
+filter those reports. But of course, the best option would be not to
+be in that situation in the first place — the more
+your custom release diverges from mainline Subversion, the more
+confusion it invites. If you must make custom releases, please try to
+keep them as temporary and as non-divergent as possible.</p>
+
+</div> <!-- custom-releases -->
+
<div class="h3" id="deprecation">
<h3>Deprecation
<a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#deprecation"
@@ -673,41 +721,6 @@ manager.</p>
</div> <!-- release-creating -->
-<div class="h2" id="custom-releases">
-<h2>Custom releases
- <a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#custom-releases"
- title="Link to this section">¶</a>
-</h2>
-
-<p>It is preferred to use the patch process and have your changes
-accepted and applied to trunk to be released on the normal Subversion
-release schedule. However, if you feel that you need to make changes
-that would not be widely accepted by the Subversion developer
-community, or need to provide early access to unreleased features, you
-should follow the guidelines below.</p>
-
-<p>First, make sure you follow the <a
-href="http://www.apache.org/foundation/marks/";>ASF
-trademark policy</a>. You will need to differentiate your release
-from the standard Subversion releases to reduce any potential
-confusion caused by your custom release.</p>
-
-<p>Second, consider creating a branch in the public Subversion
-repository to track your changes and to potentially allow your custom
-changes to be merged into mainline Subversion.</p>
-
-<p>Third, if your custom release is likely to generate bug reports
-that would not be relevant to mainline Subversion, please stay in
-touch with the users of the custom release so you can intercept and
-filter those reports. But of course, the best option would be not to
-be in that situation in the first place — the more
-your custom release diverges from mainline Subversion, the more
-confusion it invites. If you must make custom releases, please try to
-keep them as temporary and as non-divergent as possible.</p>
-
-</div> <!-- custom-releases -->
-
-
<div class="h2" id="release-branches">
<h2>Creating and maintaining release branches
<a class="sectionlink" href="<!--#echo var="GUIDE_RELEASING_PAGE"
-->#release-branches"
