incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r443397 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-publish/guides/releasemanagement.html
Date Thu, 14 Sep 2006 16:45:58 GMT
Author: rdonkin
Date: Thu Sep 14 09:45:57 2006
New Revision: 443397

URL: http://svn.apache.org/viewvc?view=rev&rev=443397
Log:
More rough content

Modified:
    incubator/public/trunk/site-author/guides/releasemanagement.xml
    incubator/public/trunk/site-publish/guides/releasemanagement.html

Modified: incubator/public/trunk/site-author/guides/releasemanagement.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/releasemanagement.xml?view=diff&rev=443397&r1=443396&r2=443397
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Thu Sep 14 09:45:57 2006
@@ -272,6 +272,43 @@
         	add content to release documents; export not checkout
         	</p>
         </section>
+        <section id='best-practice-documentation'><title>Release Documentation</title>
+        	<p>
+Users expect that <a href='glossary-release-documentation'>release documentation</a>

+to be present in the root directory of the distribution. If copies of these documents are
required
+elsewhere, it is recommended that the release build copies them. 
+        	</p>
+        	<p>
+Incubating projects should contain the STATUS document describing. TODO: check this
+        	</p>
+        	<p>
+ RELEASE_NOTES (TODO:link). Remember to include a description of the project.
+ CHANGES (link) these may be contained in a separate document
+ (TODO: maven) or included in the RELEASE NOTES. svn log can be used to collect changes.
+  This is a good opertunity to reinforce the need for good commit messages.
+ CHANGES should also include references to bugs fixed (TODO URLS, searches in JIRA or bugzilla).
+ Include a description of the build process either in a README or BUILDING document.
+ This should include details of the dependencies (both library and tool) required to build
and run 
+ the product but may do so by reference.
+        	</p>
+        </section>
+        <section id='best-practice-status'><title>STATUS document</title>
+        	<p>
+TODO: check this TODO: the STATUS document should be checked to ensure that it is up to date
+before release. Incubator releases should do a <a href='#best-practice-audit'>legal
audit</a> 
+before releasing. The legal STATUS of the codebase should be clean before it is released.
+        	</p>
+        </section>
+        <section id='best-practice-audit'><title>Legal Audit</title>
+        	<p>
+ It is of particular importance that released code is clean. 
+ It is good practice to check the provinance of any source documents 
+ which do not have license headers. Check that dependencies (and in particular
+ those dependencies that ship in the distribution) comply with Apache policy.
+ Legal policy and interpretation changes from time to time so it is worth investing
+ a little time reading again the legal release material. 
+        	</p>
+        </section>
         <section id='best-practice-formats'><title>Compression Formats</title>
             <p>
 <a href='best-practice-distributions'>Distributions</a> of all 
@@ -695,6 +732,11 @@
 Guidelines are documented recommendations which have not yet been blessed as policy.
 There are usually good reasons why project should follow the guidelines given
 even if these may be initially obvious.
+        	</p>
+        </section>
+                <section id='glossary-release-documentation'><title>Release Documentation</title>
+        	<p>
+Documents a particular release of a product rather than the product itself.
         	</p>
         </section>
     </section>

Modified: incubator/public/trunk/site-publish/guides/releasemanagement.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/releasemanagement.html?view=diff&rev=443397&r1=443396&r2=443397
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Thu Sep 14 09:45:57
2006
@@ -388,6 +388,52 @@
         	</p>
 </div>
 <h3>
+   <a name="best-practice-documentation">Release Documentation</a>
+</h3>
+<div class="section-content">
+<p>
+Users expect that <a href="glossary-release-documentation">release documentation</a>

+to be present in the root directory of the distribution. If copies of these documents are
required
+elsewhere, it is recommended that the release build copies them. 
+        	</p>
+<p>
+Incubating projects should contain the STATUS document describing. TODO: check this
+        	</p>
+<p>
+ RELEASE_NOTES (TODO:link). Remember to include a description of the project.
+ CHANGES (link) these may be contained in a separate document
+ (TODO: maven) or included in the RELEASE NOTES. svn log can be used to collect changes.
+  This is a good opertunity to reinforce the need for good commit messages.
+ CHANGES should also include references to bugs fixed (TODO URLS, searches in JIRA or bugzilla).
+ Include a description of the build process either in a README or BUILDING document.
+ This should include details of the dependencies (both library and tool) required to build
and run 
+ the product but may do so by reference.
+        	</p>
+</div>
+<h3>
+   <a name="best-practice-status">STATUS document</a>
+</h3>
+<div class="section-content">
+<p>
+TODO: check this TODO: the STATUS document should be checked to ensure that it is up to date
+before release. Incubator releases should do a <a href="#best-practice-audit">legal
audit</a> 
+before releasing. The legal STATUS of the codebase should be clean before it is released.
+        	</p>
+</div>
+<h3>
+   <a name="best-practice-audit">Legal Audit</a>
+</h3>
+<div class="section-content">
+<p>
+ It is of particular importance that released code is clean. 
+ It is good practice to check the provinance of any source documents 
+ which do not have license headers. Check that dependencies (and in particular
+ those dependencies that ship in the distribution) comply with Apache policy.
+ Legal policy and interpretation changes from time to time so it is worth investing
+ a little time reading again the legal release material. 
+        	</p>
+</div>
+<h3>
    <a name="best-practice-formats">Compression Formats</a>
 </h3>
 <div class="section-content">
@@ -915,6 +961,14 @@
 Guidelines are documented recommendations which have not yet been blessed as policy.
 There are usually good reasons why project should follow the guidelines given
 even if these may be initially obvious.
+        	</p>
+</div>
+<h3>
+   <a name="glossary-release-documentation">Release Documentation</a>
+</h3>
+<div class="section-content">
+<p>
+Documents a particular release of a product rather than the product itself.
         	</p>
 </div>
 </div>



---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message