incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j...@apache.org
Subject svn commit: r805940 - in /incubator/public/trunk: site-author/guides/releasemanagement.xml site-publish/guides/releasemanagement.html site-publish/sitemap.html
Date Wed, 19 Aug 2009 19:21:46 GMT
Author: joes
Date: Wed Aug 19 19:21:45 2009
New Revision: 805940

URL: http://svn.apache.org/viewvc?rev=805940&view=rev
Log:
s/distribution/release/g mostly, incorporating
some cautions about the terminology surrounding packages.

Also introduces some thought-provoking text,
but after all it's just a DRAFT document at
this point.  Patches welcome ;-)

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

Modified: incubator/public/trunk/site-author/guides/releasemanagement.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/releasemanagement.xml?rev=805940&r1=805939&r2=805940&view=diff
==============================================================================
--- incubator/public/trunk/site-author/guides/releasemanagement.xml [utf-8] (original)
+++ incubator/public/trunk/site-author/guides/releasemanagement.xml [utf-8] Wed Aug 19 19:21:45 2009
@@ -31,9 +31,11 @@
             <title>Abstract</title>
             <p>
 This document is descriptive, not normative. It aims to guide podlings through the process of release management.
+For a normative reference, instead see <a href="http://www.apache.org/dev/release.html">this FAQ</a> covering
+foundation-wide release policy.
             </p>
             <p>
-It contains advice on best practice, links to Apache release management 
+This document contains advice on best practice, links to Apache release management 
 <a href='http://www.apache.org/dev/index.html#releases'>policy and practice</a> 
 with commentary and discusses incubation release management  
 <a href='/incubation/Incubation_Policy.html#Releases'>policy</a>. 
@@ -82,6 +84,11 @@
         elsewhere. Podlings are free to accept or reject any of the recommendations. Enquiries may 
         be expected about novel or unusual practices. Best practice evolves. New ideas may be patched
         in. 
+            </p><p>
+        This document introduces terminology in common use at Apache but perhaps a bit unfamiliar to
+        people new to the organization.  Please skim the <a href='#glossary'>glossary</a> first for
+        definitions of the more commonly-used terms: artifact, source package, binary package,
+        distribution, release, and release manager.
             </p>
             </section>
 		</section>
@@ -213,7 +220,7 @@
         </p>
       </section>
       <section id='understanding-distribution'><title>Understanding Release Distribution</title>
-        <section id='understanding-upload'><title>Upload</title>
+        <section id='understanding-upload'><title>Uploading Artifacts</title>
           <p>
           The distribution upload location (<code>www.apache.org/dist</code>) for all Apache projects is the
           <code>/www/www.apache.org/dist</code> directory on <code>people.apache.org</code>.
@@ -416,9 +423,9 @@
               <li><a href='http://www.apache.org/dist/httpd/'>HTTPD</a></li>
             </ul>
             <p>
-            The common theme is that each type of distribution is grouped into a
-            subdirectory. For example, binary releases into <code>binaries</code>
-            and source releases into <code>source</code> (say). 
+            The common theme is that each type of artifact is grouped into a
+            subdirectory. For example, binary packages into <code>binaries</code>
+            and source packages into <code>source</code> (say). 
             </p>
             <p>
             Often symbolic links are created from the root of the project distribution
@@ -601,10 +608,10 @@
 <strong>Note</strong> this is not intended to replace an understanding of the release process.
         </p>
         <ul>
-            <li><a href='#glossary-distributions'>Distributions</a>
+            <li><a href='#glossary-packages'>Packages</a>
                 <ul>
-                    <li>Check compressed distributions <a href='#best-practice-formats'>unpack correctly</a></li>
-                    <li>Check documentation is readable</li>
+                    <li>Check that compressed artifacts <a href='#best-practice-formats'>unpack correctly</a></li>
+                    <li>Check that the documentation is readable</li>
                     <li>Check <a href='best-practice-distributing-libraries'>distributed libraries</a>
                     	<ul>
 	                    	<li>Check licenses for libraries are distributed together with any applicable 
@@ -630,12 +637,7 @@
                     </li>
                 </ul>
             </li>
-            <li><a href='#glossary-artifact'>Distributed Artifacts</a>
-                <ul>
-                    <li>Check <a href='#license'>LICENSE</a> and <a href='#notice'>NOTICE</a> files.</li>
-                </ul>
-            </li>
-            <li><a href='#glossary-source-distribution'>Source Distribution</a>
+            <li><a href='#glossary-source-package'>Source Package</a>
             	<ul>
             		<li>Check build instructions exist and that source <a href='#best-practice-source-build'>builds</a>
             		using these instructions</li>
@@ -816,75 +818,76 @@
             with the same name)
         	</p>
         </section>
-        <section id='best-practice-types'><title>Distribution Types</title>
+        <section id='best-practice-types'><title>Package Types</title>
         	<p>
  TODO: glossary - distribution type: based on the same tagged source built  
  TODO: Common Types of distribution
  			</p>
  			<p>
- The source distribution is canonical. Every release should create a source distribution.
- compiled languages may also wish to create binary releases. these may be platform specific.
- some project may also convenience types which package the project for particular containers.
+ The source package is canonical. Every release must revolve around a source package.
+ Compiled languages may also wish to create binary packages. These may be platform specific.
+ Some projects may issue builds (ie binary packages) which package the project for
+ particular containers.
         	</p>
         	<p>
- All types of distribution ship as <a href='best-practice-formats'>compressed artifacts</a>.
- This means a distribution type may be shipped as multiple compressed artifacts.
+ All types of packages ship as <a href='best-practice-formats'>compressed artifacts</a>.
+ This means multiple packages may be shipped as various compressed artifacts (eg tar.gz and .zip).
         	</p>
         </section>
         <section id='best-practice-downstream'><title>Downstream Packagers</title>
         	<p>
  TODO: glossary - downstream packager: takes an apache release and packages it for a particular platform.
  TODO: best practice is to work with downstream packagers and link to their packages
- rather than rl own packages. need to add notes that these are not official releases.
+ rather than roll their own packages. Need to add notes that these are not official releases.
  TODO: link to notes on working with downstream packagers
         	</p>
         	<p>
 TODO: write up gentoo wiki on good upstream. google for other distros.
         	</p>
         </section>    
-        <section id='best-practice-source'><title>Source Distributions</title>
+        <section id='best-practice-source'><title>Source Package</title>
         	<p>
-        	TODO: describe what a source distribution is; version control for distributions; 
+        	TODO: describe what a source package is; version control for source packages; 
         	add content to release documents; export not checkout
         	</p>
         	<p>
- Many would argue that for open source projects, the source distribution is the release:
+ Many would argue that for open source projects, the source package is the release:
  binaries are just for convenience. There are some pragmatic (as well as philosophical)
- reasons why a source distribution should be issued:
+ reasons why a source package should be issued:
         	</p>
         	<ul>
-        		<li>Downstream packages usually prefer to work from a source distribution.
+        		<li>Downstream packages usually prefer to work from an Apache source package.
         		Typically, they will patch the source both to apply fixes and to add elements
         		of their own build system. Being a good upstream encourages wider
         		distribution and use of the project.
         		</li>
         		<li>
-Source distributions encourages developers to modify the code base. Recruiting
+Source packages encourage developers to modify the code base. Recruiting
 new developers is vital for the long term health of an Apache project.
 				</li>
         	</ul>
         	<p>
-It is required that source distributions are included in every release.
+It is required that source packages are included in every release.
 Many packagers (for example, FreeBSD and linux distributions) prefer or demand
 to work from source releases. Archivists prefer source. Many large organizations
-prefer to verify and then build their own versions from source. A source distribution
+prefer to verify and then build their own versions from source. A source package
 is easy to create but helps to reach these audiences.
         	</p>
         </section>
-        <section id='best-practice-binary'><title>Binary Distribution</title>
+        <section id='best-practice-binary'><title>Binary Package</title>
         	<p>
-A binary distribution is any distribution that is not an exported snapshot of the source.
-Binary distributions may include source. For some projects, this makes sense.
+A binary package is any package that is not an exported snapshot of the source.
+Binary packages may include some source code. For some projects, this makes sense.
 For others, it does not.
         	</p>
         </section>
         <section id='best-practice-documentation'><title>Release Documentation</title>
         	<p>
 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
+to be present in the root directory of the package. 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>
-including source distributions.
+should be present in all <a href='#best-practice-types'>types of packages</a>
+including source packages.
 So the master documents should be checked into the base subversion directory.
         	</p>
         	<p>
@@ -937,7 +940,7 @@
         <section id='best-practice-license'><title>LICENSE and NOTICE</title>
         	<p>
 Apache projects may distribute artifacts and documents as part of a release
-which are not Apache Licensed. TODO link to policy. 
+which are not Apache Licensed.
         	</p>
         	<p>
 The artifacts and documents to which each subsidiary clause applies should be 
@@ -945,29 +948,39 @@
 (courtesy of <a href='http://httpd.apache.org'>Apache HTTPD</a>) is a
 good example. The Apache License is at the top of the LICENSE document. The
 explanation is clear and the files to which the licenses apply are clearly noted.
-        	</p>
+In short, all the licenses on all the files to be included within the package
+should be included, or at a minimum referenced (discouraged but acceptable for now),
+in the LICENSE document.
+        	</p>
+                <p>
+The NOTICE document is for additional copyright and attribution statements those
+licenses may require.  A typical NOTICE document at a minimum includes a Copyright
+and attribution statement for The Apache Software Foundation.  Nothing else
+belongs in the NOTICE document.  See <a href="http://www.apache.org/legal/src-headers.html#notice">
+this document</a>for the typical example.
+                </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 provenance 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.
+ those dependencies that ship in the packages) 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 
+<a href='best-practice-packages'>Packages</a> of all 
 <a href='best-practice-types'>types</a> should be shipped in a compress format
 to minimize bandwidth requirements. 
 			</p><p>
 Though utilities for all major compression formats are available for all major platforms,
 not all platforms support all major compression formats by default. 
-Users find it convenient to download the distribution compressed in a familiar
+Users find it convenient to download the package compressed in a familiar
 format that is easy to decompress on their platform.
-It is therefore recommended that each type of distribution is shipped in a variety of
+It is therefore recommended that each type of package is shipped in a variety of
 compressed formats. Ship at least one of tar.gz, bz or bz2 for UNIX and linux (but note 
 <a href='notes-on-compression-formats'>this</a>). 
 Ship zip for windows. 
@@ -979,16 +992,16 @@
 For example, <code>zip</code> with <code>windows</code> and <code>tar.gz</code>
 with <code>UNIX</code> and <code>linux</code>.
 Users often expect this association.
-See <a href='notes-line-endings'>notes</a> on line endings for source distributions.
+See <a href='notes-line-endings'>notes</a> on line endings for source packages.
             </p>
             <p>
-Different <a href='#best-practice-types'>distribution types</a> should unpack to 
+Different <a href='#best-practice-types'>package types</a> should unpack to 
 directories with different names. This is more convenient for users since:
 			</p>
 			<ul>
 				<li>users who download more than one type do not need to 
-				take action to ensure that unpacked distributions do not overwrite each other</li>
-				<li>it allows easy identification of different distribution types</li>
+				take action to ensure that unpacked packages do not overwrite each other</li>
+				<li>it allows easy identification of different package types</li>
 			</ul>
 			<p>
 For project, <em>Apache Foo</em> (say) with source and binary types, it is conventional for the main binary
@@ -998,7 +1011,7 @@
             </p>
             <p>
 Compressed archives should unpack into a contained directory (rather than straight 
-into the current directory). The directory into which the release unpacks should flow
+into the current directory). The directory into which the package unpacks should flow
 the standard naming convention. apache-foo.tar.gz should unpack to the apache-foo
 directory.
             </p>
@@ -1008,16 +1021,16 @@
 It is recommend that project that use Ant or Maven as build tools, use these tools to create
 the archives since these implementations work well across a range of platforms. 
 It is recommended that project which do not use these tools consider shipping the
-*nix distribution as a bz2 archive.
+*nix package as a bz2 archive.
             </p>
         </section>
-        <section id='best-practice-source-build'><title>Source Distribution Build</title>
+        <section id='best-practice-source-build'><title>Source Package Build</title>
         	<p>
 This section applies only to compiled languages.
         	</p>
             <p>
-Source distributions should contain easy instructions describing how to build the project.
-The source distribution should build from instructions contained. 
+Source packages should contain easy instructions describing how to build the project.
+The source package should build from instructions contained. 
 TODO: best practices for instructing users about building the project.
             </p>
             <p>
@@ -1027,7 +1040,7 @@
         <section id='best-practice-dependencies'><title>Dependencies</title>	
         	<p>
 TODO: information about dependencies is a FAQ. releases should indicate dependencies
-and which are optional and which required. if they are not shipped with the distribution
+and which are optional and which required. if they are not shipped with the package,
 information should be included about their official home. minimum (and max) supported versions.
         	</p>
         	<p>
@@ -1305,9 +1318,9 @@
             TODO: link to infrastructure
             </p>
             <p>
-Jars are just another form of binary distribution. If they are likely to be distributed
+Jars are just another form of binary package. If they are likely to be distributed
 (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.
+as other binary packages. In particular, LICENSE and NOTICE files must be distributed.
             </p>
             <p>
 It is convenient to include these with the META-INF directory. This can be done easily either 
@@ -1410,10 +1423,10 @@
  a project distributes several distinct products then the product name should also be included.
         	</p>
         	<p>
-For each product, each <a href='best-practice-types'>type of distribution</a> should be 
-assigned a consistent and unique name. Conventionally, source distributions use <code>src</code>
-and main binary distributions no prefix. Typically each type of distributions is made available in a number of 
-<a href='best-practice-formats'>compression format</a>. These are conventionally distinguished 
+For each product, each <a href='best-practice-types'>type of package</a> should be 
+assigned a consistent and unique name. Conventionally, source packages use <code>src</code>
+and main binary packages no prefix. Typically each type of package is made available in a number of 
+<a href='best-practice-formats'>compression formats</a>. These are conventionally distinguished 
 by the usual file type suffix.
         	</p>
         	<p>
@@ -1453,9 +1466,9 @@
 include a short description of the project and links to the apache site
             </p>
             <p>
-Whenever possible, each type of distribution should ship with the release notes.
+Whenever possible, each type of package should ship with release notes.
 The release notes document should therefore be committed to the source
-repository so that it ships with the source distribution.
+repository so that it ships with the source package.
             </p>
             <p>
 The first paragraph of the release notes should introduce the project and the release.
@@ -1576,8 +1589,8 @@
         </section>
         <section id='note-on-multiple-products'><title>On Multiple Products</title>
         	<p>
-A project may release a number of distinction products created by the same community.
-TODO: differences between products and distributions.
+A project may release a number of distinct products created by the same community.
+TODO: differences between products and packages.
         	</p>
         </section>
         <section id='notes-on-templates'><title>On Template Sources</title>
@@ -1590,7 +1603,7 @@
 			</p>
 			<p>
 If these templates are used to generate documents which form part of the 
-distribution then the documents generated should contain the license header.
+package then the documents generated should contain the license header.
         	</p>
         	<p>
 However, if this template is used by a user to generate output, usually
@@ -1655,7 +1668,7 @@
 for the <code>zip</code> and <code>LF</code> for the <code>tar.gz</code>).
         	</p>
             <p>
-Source distributions can use <code>svn export --native-es</code>. Binary distributions
+Source packages can use <code>svn export --native-es</code>. Binary packages
 build with <a href='http://ant.apace.org'>Ant</a> can use 
 <a href='http://ant.apache.org/manual/CoreTasks/fixcrlf.html'>fixcrlf</a>.
             </p>
@@ -1809,7 +1822,7 @@
         	<p>
 The contents of the NOTICE document should be included by all downstream distributors
 and packagers. So, this is the right place for all required credits and attribution
-notices required by any of the contents of the distribution (whether legally or ethically).
+notices required by any of the contents of the package (whether legally or ethically).
 It is better to include any other types of explanations and notes
 in the RELEASE-NOTES or in a README.
         	</p>
@@ -1916,15 +1929,15 @@
         </section>
         <section id='notes-release-candidate-java'><title>On Java Release Candidates</title>
 			<p>
-This section applies to any distribution that contains re-distributable artifacts which contain version
-information but in particular binary distributions of Java contain jar files. A compliant MANIFEST 
+This section applies to any package that contains re-distributable artifacts which contain version
+information but in particular binary packages of Java contain jar files. A compliant MANIFEST 
 meta data file within each of these files should contain the implementation version.
 These are good reasons to use the release version number as the implementation version.
 This allows the exact version to be determined from just the jar.
 Unfortunately, some applications expect the format to be entirely numeric (TODO: maven?)
 			</p>
 			<p>
-This does mean that release candidates for binary distributions of this type must either
+This does mean that release candidates for binary packages of this type must either
 be rereleased with the version number as the only change or accept that artifacts will not be 
 uniquely named. Uncertainty about exact jar versions has caused nasty dependency
 issues in the past.
@@ -1938,19 +1951,20 @@
         	TODO: check information and expand
         	</p>
         </section>
-        <section id='notes-on-source-only-releases'><title>On Source Only Releases</title>
+        <section id='notes-on-source-only-releases'><title>On Source-Only Releases</title>
         	<p>
-A source only release contains only the source distribution. Though users often prefer
-binary distributions, source only releases can be useful early in the life of a project. 
+A source-only release contains only the source package. Though users often prefer
+binary packages, source-only releases can be useful early in the life of a project. 
 They require much less ceremony and encourage developers to get involved by finding 
 and fixing bugs. Occasionally, projects whose primary user base typically obtains 
 the software via a downstream repackage may prefer to release source only.
         	</p>
         </section>
-        <section id='notes-on-binary-only-releases'><title>On Binary Only Releases</title>
+        <section id='notes-on-binary-only-releases'><title>On Binary-Only Releases</title>
         	<p>
-Releases containing only binary distributions are strongly frowned upon. Open source 
-development is characterized by the accessibility of the source. Binary only distributions
+Releases containing only binary packages are not performed at The Apache Software Foundation.
+The Apache Software Foundation distributes open source software to the public.
+Open source development is characterized by the accessibility of the source. Binary-only packages
 discourage developers from interacting with the source. Every successful Apache
 project needs to recruit new developers to carry the project forward.
         	</p>
@@ -1999,7 +2013,11 @@
          </section>
         <section id='glossary-artifact'><title>Distributed Artifact</title>
         	<p>
-A file that is actually shipped.
+A file that is actually made available for download.  Note this does <strong>NOT</strong> imply
+the file is intended for wide-scale distribution to the general public.  Such
+distributions are reserved for formally-approved releases.  For instance artifacts
+included in release candidates, periodic builds, and even the code repository itself,
+are only intended for people participating in project development.
         	</p>
             <p>
             TODO (include link to infra documentation)
@@ -2007,15 +2025,12 @@
         </section>
         <section id='glossary-license'><title>LICENSE file</title>
         	<p>
-  Document containing the licenses for the distribution.
+  Document containing the licenses for the package.
         	</p>
-            <p>
-            TODO (include link to infra documentation)
-            </p>
         </section>
         <section id='glossary-notice'><title>NOTICE file</title>
             <p>
-            TODO (include link to infra documentation)
+  Document containing additional required copyright and attribute information.
             </p>
         </section>
         <section id='glossary-ceremony'><title>Ceremony</title>
@@ -2055,30 +2070,40 @@
             TODO (include link to infra documentation)
             </p>
         </section>
-        <section id='glossary-distribution'><title>Distribution</title>
+        <section id='glossary-package'><title>Package</title>
             <p>
-            TODO (include link to infra documentation)
+        A file created from a project's source code with the intent to distribute.  Note
+        this is not to be confused with the notion of a
+        <a href="http://www.google.com/search?q=define:Java+package">Java package</a>,
+        or however else the word "package" may be used by any specific programming language community.
+        Here we use it in the generic sense to refer to software packages.
+            </p>
+        </section>
+        <section id='glossary-artifact'><title>Artifact</title>
+            <p>
+            Artifact is a generic term for a package, or more generally a file of any kind.
             </p>
         </section>
-        <section id='glossary-distribution-type'><title>Distribution Type</title>
+        <section id='glossary-package-type'><title>Package Type</title>
             <p>
             TODO (include link to infra documentation)
             </p>
         </section>
-        <section id='glossary-source-distribution'><title>Source Distribution</title>
+        <section id='glossary-source-package'><title>Source Package</title>
             <p>
-A source release is a simple export from the repository.
+A source package is typically a simple export from the repository, optionally
+with some preconfiguration scripts run on it.
             </p>
         </section>
-        <section id='glossary-binary-distribution'><title>Binary Distribution</title>
+        <section id='glossary-binary-package'><title>Binary Package</title>
             <p>
-Binary distributions are all which are not plain source exports
-There is on one canonical source distribution but there may be several binary distributions.
+Binary packages are typically platform-specific builds of the source package.
+There is only one canonical source package but there may be several binary packages.
             </p>
         </section>
         <section id='glossary-cutting-release'><title>Cutting The Release</title>
         	<p>
-The actual execution of the release. Typically consists of building the distributions
+The actual execution of the release. Typically consists of building the packages
 from the repository tag.
 TODO: link to infra
         	</p>
@@ -2165,7 +2190,7 @@
             <a href='#distribution-policy-overview'>Distribution policy overview</a>
             </li>
             <li>
-            <a href='#understanding-upload'>Uploading distributions</a>
+            <a href='#understanding-upload'>Uploading packages</a>
             </li>
           </ul>
         </section>

Modified: incubator/public/trunk/site-publish/guides/releasemanagement.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/guides/releasemanagement.html?rev=805940&r1=805939&r2=805940&view=diff
==============================================================================
--- incubator/public/trunk/site-publish/guides/releasemanagement.html [utf-8] (original)
+++ incubator/public/trunk/site-publish/guides/releasemanagement.html [utf-8] Wed Aug 19 19:21:45 2009
@@ -169,7 +169,7 @@
  </a>
  <ul>
 <li><a href='#understanding-upload'>
-Upload
+Uploading Artifacts
  </a>
 </li>
 <li><a href='#understanding-mirroring'>
@@ -305,7 +305,7 @@
  </a>
 </li>
 <li><a href='#best-practice-types'>
-Distribution Types
+Package Types
  </a>
 </li>
 <li><a href='#best-practice-downstream'>
@@ -313,11 +313,11 @@
  </a>
 </li>
 <li><a href='#best-practice-source'>
-Source Distributions
+Source Package
  </a>
 </li>
 <li><a href='#best-practice-binary'>
-Binary Distribution
+Binary Package
  </a>
 </li>
 <li><a href='#best-practice-documentation'>
@@ -341,7 +341,7 @@
  </a>
 </li>
 <li><a href='#best-practice-source-build'>
-Source Distribution Build
+Source Package Build
  </a>
 </li>
 <li><a href='#best-practice-dependencies'>
@@ -527,11 +527,11 @@
  </a>
 </li>
 <li><a href='#notes-on-source-only-releases'>
-On Source Only Releases
+On Source-Only Releases
  </a>
 </li>
 <li><a href='#notes-on-binary-only-releases'>
-On Binary Only Releases
+On Binary-Only Releases
  </a>
 </li>
 </ul>
@@ -580,20 +580,24 @@
 Release Candidate
  </a>
 </li>
-<li><a href='#glossary-distribution'>
-Distribution
+<li><a href='#glossary-package'>
+Package
  </a>
 </li>
-<li><a href='#glossary-distribution-type'>
-Distribution Type
+<li><a href='#glossary-artifact'>
+Artifact
+ </a>
+</li>
+<li><a href='#glossary-package-type'>
+Package Type
  </a>
 </li>
-<li><a href='#glossary-source-distribution'>
-Source Distribution
+<li><a href='#glossary-source-package'>
+Source Package
  </a>
 </li>
-<li><a href='#glossary-binary-distribution'>
-Binary Distribution
+<li><a href='#glossary-binary-package'>
+Binary Package
  </a>
 </li>
 <li><a href='#glossary-cutting-release'>
@@ -647,9 +651,11 @@
 <div class="section-content">
 <p>
 This document is descriptive, not normative. It aims to guide podlings through the process of release management.
+For a normative reference, instead see <a href="http://www.apache.org/dev/release.html">this FAQ</a> covering
+foundation-wide release policy.
             </p>
 <p>
-It contains advice on best practice, links to Apache release management 
+This document contains advice on best practice, links to Apache release management 
 <a href="http://www.apache.org/dev/index.html#releases">policy and practice</a> 
 with commentary and discusses incubation release management  
 <a href="/incubation/Incubation_Policy.html#Releases">policy</a>. 
@@ -711,6 +717,12 @@
         be expected about novel or unusual practices. Best practice evolves. New ideas may be patched
         in. 
             </p>
+<p>
+        This document introduces terminology in common use at Apache but perhaps a bit unfamiliar to
+        people new to the organization.  Please skim the <a href="#glossary">glossary</a> first for
+        definitions of the more commonly-used terms: artifact, source package, binary package,
+        distribution, release, and release manager.
+            </p>
 </div>
 </div>
 <h3>
@@ -790,7 +802,7 @@
 </h3>
 <div class="section-content">
 <h4>
-   <a name="understanding-upload">Upload</a>
+   <a name="understanding-upload">Uploading Artifacts</a>
 </h4>
 <div class="section-content">
 <p>
@@ -1046,9 +1058,9 @@
               <li><a href="http://www.apache.org/dist/httpd/">HTTPD</a></li>
             </ul>
 <p>
-            The common theme is that each type of distribution is grouped into a
-            subdirectory. For example, binary releases into <code>binaries</code>
-            and source releases into <code>source</code> (say). 
+            The common theme is that each type of artifact is grouped into a
+            subdirectory. For example, binary packages into <code>binaries</code>
+            and source packages into <code>source</code> (say). 
             </p>
 <p>
             Often symbolic links are created from the root of the project distribution
@@ -1246,10 +1258,10 @@
 <strong>Note</strong> this is not intended to replace an understanding of the release process.
         </p>
 <ul>
-            <li><a href="#glossary-distributions">Distributions</a>
+            <li><a href="#glossary-packages">Packages</a>
                 <ul>
-                    <li>Check compressed distributions <a href="#best-practice-formats">unpack correctly</a></li>
-                    <li>Check documentation is readable</li>
+                    <li>Check that compressed artifacts <a href="#best-practice-formats">unpack correctly</a></li>
+                    <li>Check that the documentation is readable</li>
                     <li>Check <a href="best-practice-distributing-libraries">distributed libraries</a>
                     	<ul>
 	                    	<li>Check licenses for libraries are distributed together with any applicable 
@@ -1275,12 +1287,7 @@
                     </li>
                 </ul>
             </li>
-            <li><a href="#glossary-artifact">Distributed Artifacts</a>
-                <ul>
-                    <li>Check <a href="#license">LICENSE</a> and <a href="#notice">NOTICE</a> files.</li>
-                </ul>
-            </li>
-            <li><a href="#glossary-source-distribution">Source Distribution</a>
+            <li><a href="#glossary-source-package">Source Package</a>
             	<ul>
             		<li>Check build instructions exist and that source <a href="#best-practice-source-build">builds</a>
             		using these instructions</li>
@@ -1496,7 +1503,7 @@
         	</p>
 </div>
 <h3>
-   <a name="best-practice-types">Distribution Types</a>
+   <a name="best-practice-types">Package Types</a>
 </h3>
 <div class="section-content">
 <p>
@@ -1504,13 +1511,14 @@
  TODO: Common Types of distribution
  			</p>
 <p>
- The source distribution is canonical. Every release should create a source distribution.
- compiled languages may also wish to create binary releases. these may be platform specific.
- some project may also convenience types which package the project for particular containers.
+ The source package is canonical. Every release must revolve around a source package.
+ Compiled languages may also wish to create binary packages. These may be platform specific.
+ Some projects may issue builds (ie binary packages) which package the project for
+ particular containers.
         	</p>
 <p>
- All types of distribution ship as <a href="best-practice-formats">compressed artifacts</a>.
- This means a distribution type may be shipped as multiple compressed artifacts.
+ All types of packages ship as <a href="best-practice-formats">compressed artifacts</a>.
+ This means multiple packages may be shipped as various compressed artifacts (eg tar.gz and .zip).
         	</p>
 </div>
 <h3>
@@ -1520,7 +1528,7 @@
 <p>
  TODO: glossary - downstream packager: takes an apache release and packages it for a particular platform.
  TODO: best practice is to work with downstream packagers and link to their packages
- rather than rl own packages. need to add notes that these are not official releases.
+ rather than roll their own packages. Need to add notes that these are not official releases.
  TODO: link to notes on working with downstream packagers
         	</p>
 <p>
@@ -1528,44 +1536,44 @@
         	</p>
 </div>
 <h3>
-   <a name="best-practice-source">Source Distributions</a>
+   <a name="best-practice-source">Source Package</a>
 </h3>
 <div class="section-content">
 <p>
-        	TODO: describe what a source distribution is; version control for distributions; 
+        	TODO: describe what a source package is; version control for source packages; 
         	add content to release documents; export not checkout
         	</p>
 <p>
- Many would argue that for open source projects, the source distribution is the release:
+ Many would argue that for open source projects, the source package is the release:
  binaries are just for convenience. There are some pragmatic (as well as philosophical)
- reasons why a source distribution should be issued:
+ reasons why a source package should be issued:
         	</p>
 <ul>
-        		<li>Downstream packages usually prefer to work from a source distribution.
+        		<li>Downstream packages usually prefer to work from an Apache source package.
         		Typically, they will patch the source both to apply fixes and to add elements
         		of their own build system. Being a good upstream encourages wider
         		distribution and use of the project.
         		</li>
         		<li>
-Source distributions encourages developers to modify the code base. Recruiting
+Source packages encourage developers to modify the code base. Recruiting
 new developers is vital for the long term health of an Apache project.
 				</li>
         	</ul>
 <p>
-It is required that source distributions are included in every release.
+It is required that source packages are included in every release.
 Many packagers (for example, FreeBSD and linux distributions) prefer or demand
 to work from source releases. Archivists prefer source. Many large organizations
-prefer to verify and then build their own versions from source. A source distribution
+prefer to verify and then build their own versions from source. A source package
 is easy to create but helps to reach these audiences.
         	</p>
 </div>
 <h3>
-   <a name="best-practice-binary">Binary Distribution</a>
+   <a name="best-practice-binary">Binary Package</a>
 </h3>
 <div class="section-content">
 <p>
-A binary distribution is any distribution that is not an exported snapshot of the source.
-Binary distributions may include source. For some projects, this makes sense.
+A binary package is any package that is not an exported snapshot of the source.
+Binary packages may include some source code. For some projects, this makes sense.
 For others, it does not.
         	</p>
 </div>
@@ -1575,10 +1583,10 @@
 <div class="section-content">
 <p>
 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
+to be present in the root directory of the package. 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>
-including source distributions.
+should be present in all <a href="#best-practice-types">types of packages</a>
+including source packages.
 So the master documents should be checked into the base subversion directory.
         	</p>
 <p>
@@ -1637,7 +1645,7 @@
 <div class="section-content">
 <p>
 Apache projects may distribute artifacts and documents as part of a release
-which are not Apache Licensed. TODO link to policy. 
+which are not Apache Licensed.
         	</p>
 <p>
 The artifacts and documents to which each subsidiary clause applies should be 
@@ -1645,7 +1653,17 @@
 (courtesy of <a href="http://httpd.apache.org">Apache HTTPD</a>) is a
 good example. The Apache License is at the top of the LICENSE document. The
 explanation is clear and the files to which the licenses apply are clearly noted.
+In short, all the licenses on all the files to be included within the package
+should be included, or at a minimum referenced (discouraged but acceptable for now),
+in the LICENSE document.
         	</p>
+<p>
+The NOTICE document is for additional copyright and attribution statements those
+licenses may require.  A typical NOTICE document at a minimum includes a Copyright
+and attribution statement for The Apache Software Foundation.  Nothing else
+belongs in the NOTICE document.  See <a href="http://www.apache.org/legal/src-headers.html#notice">
+this document</a>for the typical example.
+                </p>
 </div>
 <h3>
    <a name="best-practice-audit">Legal Audit</a>
@@ -1655,7 +1673,7 @@
  It is of particular importance that released code is clean. 
  It is good practice to check the provenance 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.
+ those dependencies that ship in the packages) 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>
@@ -1665,16 +1683,16 @@
 </h3>
 <div class="section-content">
 <p>
-<a href="best-practice-distributions">Distributions</a> of all 
+<a href="best-practice-packages">Packages</a> of all 
 <a href="best-practice-types">types</a> should be shipped in a compress format
 to minimize bandwidth requirements. 
 			</p>
 <p>
 Though utilities for all major compression formats are available for all major platforms,
 not all platforms support all major compression formats by default. 
-Users find it convenient to download the distribution compressed in a familiar
+Users find it convenient to download the package compressed in a familiar
 format that is easy to decompress on their platform.
-It is therefore recommended that each type of distribution is shipped in a variety of
+It is therefore recommended that each type of package is shipped in a variety of
 compressed formats. Ship at least one of tar.gz, bz or bz2 for UNIX and linux (but note 
 <a href="notes-on-compression-formats">this</a>). 
 Ship zip for windows. 
@@ -1687,16 +1705,16 @@
 For example, <code>zip</code> with <code>windows</code> and <code>tar.gz</code>
 with <code>UNIX</code> and <code>linux</code>.
 Users often expect this association.
-See <a href="notes-line-endings">notes</a> on line endings for source distributions.
+See <a href="notes-line-endings">notes</a> on line endings for source packages.
             </p>
 <p>
-Different <a href="#best-practice-types">distribution types</a> should unpack to 
+Different <a href="#best-practice-types">package types</a> should unpack to 
 directories with different names. This is more convenient for users since:
 			</p>
 <ul>
 				<li>users who download more than one type do not need to 
-				take action to ensure that unpacked distributions do not overwrite each other</li>
-				<li>it allows easy identification of different distribution types</li>
+				take action to ensure that unpacked packages do not overwrite each other</li>
+				<li>it allows easy identification of different package types</li>
 			</ul>
 <p>
 For project, <em>Apache Foo</em> (say) with source and binary types, it is conventional for the main binary
@@ -1706,7 +1724,7 @@
             </p>
 <p>
 Compressed archives should unpack into a contained directory (rather than straight 
-into the current directory). The directory into which the release unpacks should flow
+into the current directory). The directory into which the package unpacks should flow
 the standard naming convention. apache-foo.tar.gz should unpack to the apache-foo
 directory.
             </p>
@@ -1716,19 +1734,19 @@
 It is recommend that project that use Ant or Maven as build tools, use these tools to create
 the archives since these implementations work well across a range of platforms. 
 It is recommended that project which do not use these tools consider shipping the
-*nix distribution as a bz2 archive.
+*nix package as a bz2 archive.
             </p>
 </div>
 <h3>
-   <a name="best-practice-source-build">Source Distribution Build</a>
+   <a name="best-practice-source-build">Source Package Build</a>
 </h3>
 <div class="section-content">
 <p>
 This section applies only to compiled languages.
         	</p>
 <p>
-Source distributions should contain easy instructions describing how to build the project.
-The source distribution should build from instructions contained. 
+Source packages should contain easy instructions describing how to build the project.
+The source package should build from instructions contained. 
 TODO: best practices for instructing users about building the project.
             </p>
 <p>
@@ -1741,7 +1759,7 @@
 <div class="section-content">
 <p>
 TODO: information about dependencies is a FAQ. releases should indicate dependencies
-and which are optional and which required. if they are not shipped with the distribution
+and which are optional and which required. if they are not shipped with the package,
 information should be included about their official home. minimum (and max) supported versions.
         	</p>
 <p>
@@ -2068,9 +2086,9 @@
             TODO: link to infrastructure
             </p>
 <p>
-Jars are just another form of binary distribution. If they are likely to be distributed
+Jars are just another form of binary package. If they are likely to be distributed
 (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.
+as other binary packages. In particular, LICENSE and NOTICE files must be distributed.
             </p>
 <p>
 It is convenient to include these with the META-INF directory. This can be done easily either 
@@ -2189,10 +2207,10 @@
  a project distributes several distinct products then the product name should also be included.
         	</p>
 <p>
-For each product, each <a href="best-practice-types">type of distribution</a> should be 
-assigned a consistent and unique name. Conventionally, source distributions use <code>src</code>
-and main binary distributions no prefix. Typically each type of distributions is made available in a number of 
-<a href="best-practice-formats">compression format</a>. These are conventionally distinguished 
+For each product, each <a href="best-practice-types">type of package</a> should be 
+assigned a consistent and unique name. Conventionally, source packages use <code>src</code>
+and main binary packages no prefix. Typically each type of package is made available in a number of 
+<a href="best-practice-formats">compression formats</a>. These are conventionally distinguished 
 by the usual file type suffix.
         	</p>
 <p>
@@ -2235,9 +2253,9 @@
 include a short description of the project and links to the apache site
             </p>
 <p>
-Whenever possible, each type of distribution should ship with the release notes.
+Whenever possible, each type of package should ship with release notes.
 The release notes document should therefore be committed to the source
-repository so that it ships with the source distribution.
+repository so that it ships with the source package.
             </p>
 <p>
 The first paragraph of the release notes should introduce the project and the release.
@@ -2373,8 +2391,8 @@
 </h3>
 <div class="section-content">
 <p>
-A project may release a number of distinction products created by the same community.
-TODO: differences between products and distributions.
+A project may release a number of distinct products created by the same community.
+TODO: differences between products and packages.
         	</p>
 </div>
 <h3>
@@ -2390,7 +2408,7 @@
 			</p>
 <p>
 If these templates are used to generate documents which form part of the 
-distribution then the documents generated should contain the license header.
+package then the documents generated should contain the license header.
         	</p>
 <p>
 However, if this template is used by a user to generate output, usually
@@ -2465,7 +2483,7 @@
 for the <code>zip</code> and <code>LF</code> for the <code>tar.gz</code>).
         	</p>
 <p>
-Source distributions can use <code>svn export --native-es</code>. Binary distributions
+Source packages can use <code>svn export --native-es</code>. Binary packages
 build with <a href="http://ant.apace.org">Ant</a> can use 
 <a href="http://ant.apache.org/manual/CoreTasks/fixcrlf.html">fixcrlf</a>.
             </p>
@@ -2640,7 +2658,7 @@
 <p>
 The contents of the NOTICE document should be included by all downstream distributors
 and packagers. So, this is the right place for all required credits and attribution
-notices required by any of the contents of the distribution (whether legally or ethically).
+notices required by any of the contents of the package (whether legally or ethically).
 It is better to include any other types of explanations and notes
 in the RELEASE-NOTES or in a README.
         	</p>
@@ -2759,15 +2777,15 @@
 </h3>
 <div class="section-content">
 <p>
-This section applies to any distribution that contains re-distributable artifacts which contain version
-information but in particular binary distributions of Java contain jar files. A compliant MANIFEST 
+This section applies to any package that contains re-distributable artifacts which contain version
+information but in particular binary packages of Java contain jar files. A compliant MANIFEST 
 meta data file within each of these files should contain the implementation version.
 These are good reasons to use the release version number as the implementation version.
 This allows the exact version to be determined from just the jar.
 Unfortunately, some applications expect the format to be entirely numeric (TODO: maven?)
 			</p>
 <p>
-This does mean that release candidates for binary distributions of this type must either
+This does mean that release candidates for binary packages of this type must either
 be rereleased with the version number as the only change or accept that artifacts will not be 
 uniquely named. Uncertainty about exact jar versions has caused nasty dependency
 issues in the past.
@@ -2785,24 +2803,25 @@
         	</p>
 </div>
 <h3>
-   <a name="notes-on-source-only-releases">On Source Only Releases</a>
+   <a name="notes-on-source-only-releases">On Source-Only Releases</a>
 </h3>
 <div class="section-content">
 <p>
-A source only release contains only the source distribution. Though users often prefer
-binary distributions, source only releases can be useful early in the life of a project. 
+A source-only release contains only the source package. Though users often prefer
+binary packages, source-only releases can be useful early in the life of a project. 
 They require much less ceremony and encourage developers to get involved by finding 
 and fixing bugs. Occasionally, projects whose primary user base typically obtains 
 the software via a downstream repackage may prefer to release source only.
         	</p>
 </div>
 <h3>
-   <a name="notes-on-binary-only-releases">On Binary Only Releases</a>
+   <a name="notes-on-binary-only-releases">On Binary-Only Releases</a>
 </h3>
 <div class="section-content">
 <p>
-Releases containing only binary distributions are strongly frowned upon. Open source 
-development is characterized by the accessibility of the source. Binary only distributions
+Releases containing only binary packages are not performed at The Apache Software Foundation.
+The Apache Software Foundation distributes open source software to the public.
+Open source development is characterized by the accessibility of the source. Binary-only packages
 discourage developers from interacting with the source. Every successful Apache
 project needs to recruit new developers to carry the project forward.
         	</p>
@@ -2863,7 +2882,11 @@
 </h3>
 <div class="section-content">
 <p>
-A file that is actually shipped.
+A file that is actually made available for download.  Note this does <strong>NOT</strong> imply
+the file is intended for wide-scale distribution to the general public.  Such
+distributions are reserved for formally-approved releases.  For instance artifacts
+included in release candidates, periodic builds, and even the code repository itself,
+are only intended for people participating in project development.
         	</p>
 <p>
             TODO (include link to infra documentation)
@@ -2874,18 +2897,15 @@
 </h3>
 <div class="section-content">
 <p>
-  Document containing the licenses for the distribution.
+  Document containing the licenses for the package.
         	</p>
-<p>
-            TODO (include link to infra documentation)
-            </p>
 </div>
 <h3>
    <a name="glossary-notice">NOTICE file</a>
 </h3>
 <div class="section-content">
 <p>
-            TODO (include link to infra documentation)
+  Document containing additional required copyright and attribute information.
             </p>
 </div>
 <h3>
@@ -2941,15 +2961,27 @@
             </p>
 </div>
 <h3>
-   <a name="glossary-distribution">Distribution</a>
+   <a name="glossary-package">Package</a>
 </h3>
 <div class="section-content">
 <p>
-            TODO (include link to infra documentation)
+        A file created from a project's source code with the intent to distribute.  Note
+        this is not to be confused with the notion of a
+        <a href="http://www.google.com/search?q=define:Java+package">Java package</a>,
+        or however else the word "package" may be used by any specific programming language community.
+        Here we use it in the generic sense to refer to software packages.
+            </p>
+</div>
+<h3>
+   <a name="glossary-artifact">Artifact</a>
+</h3>
+<div class="section-content">
+<p>
+            Artifact is a generic term for a package, or more generally a file of any kind.
             </p>
 </div>
 <h3>
-   <a name="glossary-distribution-type">Distribution Type</a>
+   <a name="glossary-package-type">Package Type</a>
 </h3>
 <div class="section-content">
 <p>
@@ -2957,20 +2989,21 @@
             </p>
 </div>
 <h3>
-   <a name="glossary-source-distribution">Source Distribution</a>
+   <a name="glossary-source-package">Source Package</a>
 </h3>
 <div class="section-content">
 <p>
-A source release is a simple export from the repository.
+A source package is typically a simple export from the repository, optionally
+with some preconfiguration scripts run on it.
             </p>
 </div>
 <h3>
-   <a name="glossary-binary-distribution">Binary Distribution</a>
+   <a name="glossary-binary-package">Binary Package</a>
 </h3>
 <div class="section-content">
 <p>
-Binary distributions are all which are not plain source exports
-There is on one canonical source distribution but there may be several binary distributions.
+Binary packages are typically platform-specific builds of the source package.
+There is only one canonical source package but there may be several binary packages.
             </p>
 </div>
 <h3>
@@ -2978,7 +3011,7 @@
 </h3>
 <div class="section-content">
 <p>
-The actual execution of the release. Typically consists of building the distributions
+The actual execution of the release. Typically consists of building the packages
 from the repository tag.
 TODO: link to infra
         	</p>
@@ -3087,7 +3120,7 @@
             <a href="#distribution-policy-overview">Distribution policy overview</a>
             </li>
             <li>
-            <a href="#understanding-upload">Uploading distributions</a>
+            <a href="#understanding-upload">Uploading packages</a>
             </li>
           </ul>
 </div>

Modified: incubator/public/trunk/site-publish/sitemap.html
URL: http://svn.apache.org/viewvc/incubator/public/trunk/site-publish/sitemap.html?rev=805940&r1=805939&r2=805940&view=diff
==============================================================================
--- incubator/public/trunk/site-publish/sitemap.html [utf-8] (original)
+++ incubator/public/trunk/site-publish/sitemap.html [utf-8] Wed Aug 19 19:21:45 2009
@@ -988,7 +988,7 @@
 <a href="guides/releasemanagement.html#understanding-distribution">Understanding Release Distribution</a>
 <ul>
 <li>
-<a href="guides/releasemanagement.html#understanding-upload">Upload</a>
+<a href="guides/releasemanagement.html#understanding-upload">Uploading Artifacts</a>
 </li>
 <li>
 <a href="guides/releasemanagement.html#understanding-mirroring">Mirroring</a>
@@ -1093,16 +1093,16 @@
 <a href="guides/releasemanagement.html#best-practice-naming">Artifact Naming</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#best-practice-types">Distribution Types</a>
+<a href="guides/releasemanagement.html#best-practice-types">Package Types</a>
 </li>
 <li>
 <a href="guides/releasemanagement.html#best-practice-downstream">Downstream Packagers</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#best-practice-source">Source Distributions</a>
+<a href="guides/releasemanagement.html#best-practice-source">Source Package</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#best-practice-binary">Binary Distribution</a>
+<a href="guides/releasemanagement.html#best-practice-binary">Binary Package</a>
 </li>
 <li>
 <a href="guides/releasemanagement.html#best-practice-documentation">Release Documentation</a>
@@ -1120,7 +1120,7 @@
 <a href="guides/releasemanagement.html#best-practice-formats">Compression Formats</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#best-practice-source-build">Source Distribution Build</a>
+<a href="guides/releasemanagement.html#best-practice-source-build">Source Package Build</a>
 </li>
 <li>
 <a href="guides/releasemanagement.html#best-practice-dependencies">Dependencies</a>
@@ -1261,10 +1261,10 @@
 <a href="guides/releasemanagement.html#notes-on-gnu-tar">GNU Tar Known Incompatibilities</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#notes-on-source-only-releases">On Source Only Releases</a>
+<a href="guides/releasemanagement.html#notes-on-source-only-releases">On Source-Only Releases</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#notes-on-binary-only-releases">On Binary Only Releases</a>
+<a href="guides/releasemanagement.html#notes-on-binary-only-releases">On Binary-Only Releases</a>
 </li>
 </ul>
 </li>
@@ -1302,16 +1302,19 @@
 <a href="guides/releasemanagement.html#glossary-release-candidate">Release Candidate</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#glossary-distribution">Distribution</a>
+<a href="guides/releasemanagement.html#glossary-package">Package</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#glossary-distribution-type">Distribution Type</a>
+<a href="guides/releasemanagement.html#glossary-artifact">Artifact</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#glossary-source-distribution">Source Distribution</a>
+<a href="guides/releasemanagement.html#glossary-package-type">Package Type</a>
 </li>
 <li>
-<a href="guides/releasemanagement.html#glossary-binary-distribution">Binary Distribution</a>
+<a href="guides/releasemanagement.html#glossary-source-package">Source Package</a>
+</li>
+<li>
+<a href="guides/releasemanagement.html#glossary-binary-package">Binary Package</a>
 </li>
 <li>
 <a href="guides/releasemanagement.html#glossary-cutting-release">Cutting The Release</a>



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


Mime
View raw message