incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rdon...@apache.org
Subject svn commit: r608246 - /incubator/public/trunk/site-publish/guides/releasemanagement.html
Date Wed, 02 Jan 2008 21:51:32 GMT
Author: rdonkin
Date: Wed Jan  2 13:51:31 2008
New Revision: 608246

URL: http://svn.apache.org/viewvc?rev=608246&view=rev
Log:
Regenerated after Curt's improvements.

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

Modified: incubator/public/trunk/site-publish/guides/releasemanagement.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/releasemanagement.html?rev=608246&r1=608245&r2=608246&view=diff
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html Wed Jan  2 13:51:31
2008
@@ -1476,7 +1476,7 @@
 </h3>
 <div class="section-content">
 <p>
-Users expect <a href="glossary-release-documentation">release documentation</a>

+Users expect <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 process creates copies. These documents
 should be present in all <a href="#best-practice-types">types of distribution</a>
@@ -1721,7 +1721,7 @@
 </h3>
 <div class="section-content">
 <p>
-        	TODO: svn is flexible. branches and tags are not the same as svn.
+        	TODO: svn is flexible. branches and tags with svn are not the same as with cvs.
         	</p>
 <p>
 All releases should be built from a tag. It is occasionally necessary to rebuild
@@ -1730,7 +1730,7 @@
 So, every release and candidate should be tagged. 
         	</p>
 <p>
-It is useful to adopt a reasonable naming convention when tagging releases.
+It is useful to adopt a consistent naming convention for tagging releases.
 This allows release tags to be recognized easily. Typically the tag will be a
 variation on the name of the release. For example, some projects use
 ALL CAPS to indicate release tags in which can apache-foo-1.2 would be tagged
@@ -1749,8 +1749,8 @@
 <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 permanently archived. 
-It is very occasionally necessary (for example, for legal reasons) 
-to alter some small parts of a release or simply to recreate an d release.
+It may be necessary (for example, for legal reasons) 
+to provide a new release that is a slight alteration of a previous release.
 Release managers owe it to those who come afterwards to use build processes
 that are reproducible.
 			</p>
@@ -1761,7 +1761,7 @@
         	</p>
 <p>
 The requirements of the build should be fully documented. The versions of tools 
-used to build the release should be noted.
+and platforms used to build the release should be noted.
         	</p>
 </div>
 <h3>
@@ -1770,7 +1770,7 @@
 <div class="section-content">
 <p>
 Releases are a primary form of communication with open source users and potential developers.
-It's useful to think about releases in this way. TODO: what a release says about a projects

+Its useful to think about releases in this way. TODO: what a release says about a projects

 TODO: link into media relations and announcements (grassroots and mainstream, articles
 on new features, freshmeat, downstream packagers)
         	</p>
@@ -1866,10 +1866,10 @@
 adopted by a the project.
 			</p>
 <p>
-Those release adopting a system of blessing a candidate will start by creating a
+Those projects adopting a system of blessing a candidate will start by creating a
 candidate which will then be promoted by a series of votes until it either fails
-or reaches full release status. In this case the same candidate will
-be know as a release candidate, an alpha, a beta and then a full release.
+or reaches full release status. In this case, the same candidate may
+be known as a release candidate, an alpha, a beta and then a full release.
         	</p>
 <p>
 Those projects which releases candidates will vote on a sample release candidate.
@@ -1890,7 +1890,7 @@
 <p>
 It is traditional that release managers use their Apache home space to make available
 release candidates. TODO:link to dev instructions on using Apache web space.
-Please remember to delete d releases.
+Please remember to delete release candidates after voting concludes.
         	</p>
 </div>
 <h3>
@@ -1914,7 +1914,7 @@
 </h3>
 <div class="section-content">
 <p>
-<a href="http://maven.apache.org">Apache Maven</a> is a to used by many podlings.
+<a href="http://maven.apache.org">Apache Maven</a> is a tool used by many podlings.
 TODO: improve preamble
         	</p>
 <p>
@@ -1969,7 +1969,7 @@
             </p>
 <p>
 Jars are just another form of binary distribution. If they are likely to be distributed
-(for example, through the Apache Repository) then they must adhere to the same picy
+(for example, through the Apache Repository) then they must adhere to the same policy
 as other binary distributions. In particular, LICENSE and NOTICE files must be distributed.
             </p>
 <p>
@@ -1983,7 +1983,7 @@
 <div class="section-content">
 <p>
 TODO
-Lots of projects get this wrong and (by default) most tos produce substandard manifests.
+Lots of projects get this wrong and most tools, by default, produce substandard manifests.
 Offer some guidance on values
 TODO: Add how to create a specification compliant MANIFEST 
 http://jakarta.apache.org/commons/releases/prepare.html#checkjarmanifest
@@ -1996,9 +1996,9 @@
             </p>
 <p>
 Maven 2 produces a much better manifest provided that the POM is reasonably full.
-It does not (by default) include some recommended. It is recommended that POM should be
+It does not, by default, include some recommended manifest entries. It is recommended that
POM should be
 <a href="http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html">customized</a>
-so that it includes the missing recommendation.
+so that it includes the missing recommended entries.
             </p>
 </div>
 <h3>
@@ -2006,7 +2006,7 @@
 </h3>
 <div class="section-content">
 <p>
-There are two distinct approaches <a href="glossary-release-candidate">release candidate</a>.
 
+There are two distinct approaches: <a href="#glossary-release-candidate">release candidate</a>
and TODO.  
         	</p>
 </div>
 <h3>
@@ -2029,7 +2029,7 @@
 <p>
  The most common system of versioning is based on <code>major.minor.point</code>
  where major, minor and point are all integers. Note that these are not decimals and
- there is no necessity to raise a major version number (say) if the minor version has
+ there is no necessity to raise a major version number after the minor version has
  reached 9. The exact rules vary and it is recommended that a project agrees and documents
  its own rules. 
 			</p>
@@ -2047,7 +2047,7 @@
  releases than to create numerous alphas and betas for 1.0. Conventionally, 0.x releases
  are aimed at early adopters only without a strong promise of easy upgrade or backwards
  compatibility. 0.x is a good designation for a product that is not feature complete 
- but whose code is sid for those features which are implemented.
+ but whose code is solid for those features which are implemented.
         	</p>
 </div>
 <h3>



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


Mime
View raw message