incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r453873 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-publish/guides/releasemanagement.html
Date Sat, 07 Oct 2006 09:14:47 GMT
Author: rdonkin
Date: Sat Oct  7 02:14:47 2006
New Revision: 453873

URL: http://svn.apache.org/viewvc?view=rev&rev=453873
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=453873&r1=453872&r2=453873
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml Sat Oct  7 02:14:47 2006
@@ -202,6 +202,7 @@
             		<li>Check <a href='glossary-license-headers'>license headers</a>

             		are <a href='notes-license-headers'>correctly applied</a></li>
             		<li>Check for <a href='#best-practice-source'>version control</a>
files</li>
+            		<li>Check that source is exported from tag</li>
             	</ul>
             </li>
          	<li>OpenPGP keys
@@ -511,14 +512,49 @@
 ALL CAPS to indicate release tags in which can apache-foo-1.2 would be tagged
 APACHE_FOO_1_2. 
         	</p>
-        </section>
-        <section id='best-practices'><title>Dependencies</title>
         	<p>
-TODO: versions should be clearly indicated
-TODO: java version with indication in MANIFEST (link to note)
+If <code>svn:externals</code> is used, check carefully that a tag is referenced.
+This ensure that all the source for the release is fixed. If the target of a <code>svn:externals</code>
+changes then the release will no longer be complete reproducable.
         	</p>
-        	<p>
-TODO: see note on export regulation complience.
+        </section>
+        <section id='best-practice-reproducability'><title>Reproducability</title>
+        	<p>
+It is important that any release can be reproduced from the source at any time in the future.

+Apache releases have long active lives and are permenantly archived. 
+It is very occasionally necessary (for example, for legal reasons) 
+to alter some small parts of a release or simply to recreate an old release.
+Release managers owe it to those who come afterwards to use build processes
+that are reproducible.
+			</p><p>
+The build script should fully capture all the processes necessary to create the release.
+Manual processing (other than creating compressed archives) is a sign that the build
+is not mature enough for a full Apache release.
+        	</p><p>
+The requirements of the build should be fully documented. The versions of tools 
+used to build the release should be noted.
+        	</p>
+        </section>
+        <section id='best-practice-dependencies'><title>Dependencies</title>
+        	<p>
+As well as libraries, projects often have more subtle dependencies.
+Many languages (for example Java and Perl) have different versions.
+It is important that the versions of a language upon which a project
+will run are clearly documented. The <a href='TODO:'>release notes</a>
+are a typical location for this information. <a href='TODO:link to note on '>Note</a>
+that Java also includes the version used to build in the MANIFEST. 
+        	</p>
+        	<p>
+It is important to review all library dependencies as part of the release process
+for compliance. Apache policy changes from time-to-time. A list should be 
+compiled of the project's dependencies, those shipped as binary libraries 
+and those shipped as source document together with the licenses for
+those dependencies. These lists should be checked against the latest policy documents.
+        	</p>
+        	<p>
+This list should also be used to check for compliance with US export regulations.
+If any dependencies are cryptographic libraries then it may be necessary
+to fill in some <a href='TODO:'>paperwork</a>. 
         	</p>
         </section>
          <section id='announcements'><title>Announcements</title>
@@ -664,6 +700,27 @@
  but whose code is solid for those features which are implemented.
         	</p>
         </section>
+        <section id='notes-numbering-between-releases'><title>Version Numbering
Between Releases</title>
+        	<p>
+It is useful to use a system of versioning for development (non-release) version numbers
that
+allows artifacts built from a development code stream to be distinguished by their version
+from releases. Choose any reasonable and appropriate system but documented it so that
+users understand how to recognize the difference.
+        	</p>
+        	<p>
+There are two major approaches to this problem. Some use a suffix to indicate a development
+stream. Others use a property of the version number (conventionally odd or even).
+        	</p>
+        	<p>
+TODO: odd, even version numbers - research httpd, linux
+        	</p>
+        	<p>
+<code>SNAPSHOT</code> and <code>dev</code> are commonly used suffixes.

+Typically these are set to the next minor version number in sequence. For example,
+after cutting <code>apache-foo-1.5.6</code>, the version would be 
+<code>1.6</code>. 
+        	</p>
+        </section>
         <section id='best-practice-unique-names'><title>Unique Artifact Names</title>
         	<p>
  Every <a href='glossay-artifact'>artifact</a> distributed should have a name
that is unique.
@@ -937,10 +994,15 @@
 example</a>. 
 			</p>
 			<p>
+Be careful to check the voters against the appropriate list. Binding votes are cast by people
on the 
+appropriate committee. The list of incubator PMCers is available TODO: link online. Note
that 
+sometimes the online lists are out of date. TODO: link to foundation site.
+			</p>
+			<p>
 The result post should list each voter and the vote cast. Non binding votes may be listed.
If they are 
 then each binding vote should be indicated. If they are not then the post should state that
only binding
 votes have been included.
-Each voter can (and should) verify that their vote has been correctly tallied.
+Each voter can (and should) verify that their vote has been correctly tallied. TODO link
to problem thread.
         	</p>
         	<p>
 When posting replies to a VOTE thread take particular care to change the subject.

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=453873&r1=453872&r2=453873
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Sat Oct  7 02:14:47
2006
@@ -295,6 +295,7 @@
             		<li>Check <a href="glossary-license-headers">license headers</a>

             		are <a href="notes-license-headers">correctly applied</a></li>
             		<li>Check for <a href="#best-practice-source">version control</a>
files</li>
+            		<li>Check that source is exported from tag</li>
             	</ul>
             </li>
          	<li>OpenPGP keys
@@ -665,17 +666,57 @@
 ALL CAPS to indicate release tags in which can apache-foo-1.2 would be tagged
 APACHE_FOO_1_2. 
         	</p>
+<p>
+If <code>svn:externals</code> is used, check carefully that a tag is referenced.
+This ensure that all the source for the release is fixed. If the target of a <code>svn:externals</code>
+changes then the release will no longer be complete reproducable.
+        	</p>
 </div>
 <h3>
-   <a name="best-practices">Dependencies</a>
+   <a name="best-practice-reproducability">Reproducability</a>
 </h3>
 <div class="section-content">
 <p>
-TODO: versions should be clearly indicated
-TODO: java version with indication in MANIFEST (link to note)
+It is important that any release can be reproduced from the source at any time in the future.

+Apache releases have long active lives and are permenantly archived. 
+It is very occasionally necessary (for example, for legal reasons) 
+to alter some small parts of a release or simply to recreate an old release.
+Release managers owe it to those who come afterwards to use build processes
+that are reproducible.
+			</p>
+<p>
+The build script should fully capture all the processes necessary to create the release.
+Manual processing (other than creating compressed archives) is a sign that the build
+is not mature enough for a full Apache release.
         	</p>
 <p>
-TODO: see note on export regulation complience.
+The requirements of the build should be fully documented. The versions of tools 
+used to build the release should be noted.
+        	</p>
+</div>
+<h3>
+   <a name="best-practice-dependencies">Dependencies</a>
+</h3>
+<div class="section-content">
+<p>
+As well as libraries, projects often have more subtle dependencies.
+Many languages (for example Java and Perl) have different versions.
+It is important that the versions of a language upon which a project
+will run are clearly documented. The <a href="TODO:">release notes</a>
+are a typical location for this information. <a href="TODO:link to note on ">Note</a>
+that Java also includes the version used to build in the MANIFEST. 
+        	</p>
+<p>
+It is important to review all library dependencies as part of the release process
+for compliance. Apache policy changes from time-to-time. A list should be 
+compiled of the project's dependencies, those shipped as binary libraries 
+and those shipped as source document together with the licenses for
+those dependencies. These lists should be checked against the latest policy documents.
+        	</p>
+<p>
+This list should also be used to check for compliance with US export regulations.
+If any dependencies are cryptographic libraries then it may be necessary
+to fill in some <a href="TODO:">paperwork</a>. 
         	</p>
 </div>
 <h3>
@@ -847,6 +888,30 @@
         	</p>
 </div>
 <h3>
+   <a name="notes-numbering-between-releases">Version Numbering Between Releases</a>
+</h3>
+<div class="section-content">
+<p>
+It is useful to use a system of versioning for development (non-release) version numbers
that
+allows artifacts built from a development code stream to be distinguished by their version
+from releases. Choose any reasonable and appropriate system but documented it so that
+users understand how to recognize the difference.
+        	</p>
+<p>
+There are two major approaches to this problem. Some use a suffix to indicate a development
+stream. Others use a property of the version number (conventionally odd or even).
+        	</p>
+<p>
+TODO: odd, even version numbers - research httpd, linux
+        	</p>
+<p>
+<code>SNAPSHOT</code> and <code>dev</code> are commonly used suffixes.

+Typically these are set to the next minor version number in sequence. For example,
+after cutting <code>apache-foo-1.5.6</code>, the version would be 
+<code>1.6</code>. 
+        	</p>
+</div>
+<h3>
    <a name="best-practice-unique-names">Unique Artifact Names</a>
 </h3>
 <div class="section-content">
@@ -1159,10 +1224,15 @@
 example</a>. 
 			</p>
 <p>
+Be careful to check the voters against the appropriate list. Binding votes are cast by people
on the 
+appropriate committee. The list of incubator PMCers is available TODO: link online. Note
that 
+sometimes the online lists are out of date. TODO: link to foundation site.
+			</p>
+<p>
 The result post should list each voter and the vote cast. Non binding votes may be listed.
If they are 
 then each binding vote should be indicated. If they are not then the post should state that
only binding
 votes have been included.
-Each voter can (and should) verify that their vote has been correctly tallied.
+Each voter can (and should) verify that their vote has been correctly tallied. TODO link
to problem thread.
         	</p>
 <p>
 When posting replies to a VOTE thread take particular care to change the subject.



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


Mime
View raw message