incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mar...@apache.org
Subject svn commit: r1369718 - /incubator/public/trunk/content/guides/releasemanagement.xml
Date Mon, 06 Aug 2012 03:32:45 GMT
Author: marvin
Date: Mon Aug  6 03:32:45 2012
New Revision: 1369718

URL: http://svn.apache.org/viewvc?rev=1369718&view=rev
Log:
Remove Java-specific passages from primary release page.

All Java-specific passages have been duplicated in the sub-page
release-java.html, so remove them from the primary page.

Modified:
    incubator/public/trunk/content/guides/releasemanagement.xml

Modified: incubator/public/trunk/content/guides/releasemanagement.xml
URL: http://svn.apache.org/viewvc/incubator/public/trunk/content/guides/releasemanagement.xml?rev=1369718&r1=1369717&r2=1369718&view=diff
==============================================================================
--- incubator/public/trunk/content/guides/releasemanagement.xml [utf-8] (original)
+++ incubator/public/trunk/content/guides/releasemanagement.xml [utf-8] Mon Aug  6 03:32:45
2012
@@ -214,11 +214,6 @@ TODO: maybe be better in a time line
              distributing a release, esp. when your release artifacts are huge.
          </p>
      </div>
-    <!--
-    TODO:                
-        Maven: 
-          Stop ignoring the elephant
-       -->
       <section id='distribution-policy-overview'><title>Policy Overview</title>
         <p>
         Distribution policy with regard to releases is simple:
@@ -601,37 +596,6 @@ TODO: maybe be better in a time line
           <li>Adding a suitable notice to the download page</li>
           </ol>
         </section>
-        <section id='distributing-eclipse'><title>Eclipse Update Site</title>
-          <p>
-          Podlings may distribute suitable artifacts through an 
-          <a href='http://www.eclipse.org'>Eclipse</a> update site.
-          All artifacts distributed through the update site must satisfy the standard
-          <a href='#distribution-policy-overview'>policy</a>. This implies that:
-          </p>
-          <ul>
-            <li>The update site must be contained within the  
-            <a href='#glossary-podling-dist'>podling distribution directory</a>.</li>
-            <li>All artifacts must be 
-            <a href='http://www.apache.org/dev/release-signing.html#keys-policy'>signed
and summed</a>.</li>
-            <li><a href='#distribution-mirroring'>Mirroring</a> must be
used.</li>
-          </ul>
-          <p>Detailed instructions on how to setup an Incubator Project to have an

-            <a href='releasing-eclipse-update-site.html'>Eclipse update site with Mirroring</a>
are available.</p>
-          <!--  
-          <p>
-          Mirroring an update site requires some additional effort. The <code>mirrorsURL</code>
attribute
-          of the root <code>site</code> element in the <code>site.xml</code>
should be set the URL
-          of a mirroring script. For example
-          </p>
-          <source>
-          &lt;site mirrorsURL="http://incubator.apache.org/mirrors-support/{podling}-eclipse-update-
-xml.cgi"&gt;
-            &lt;description&gt;Apache {Podling} Eclipse Update Site&lt;/description&gt;
-            ...
-          &lt;/site&gt;
-          </source>
-          
-          -->
-        </section>
       </section>
     </section> 
     
@@ -792,7 +756,6 @@ lists. Subscribe to:
     	</p>
         <ul>
             <li><em>legal-discuss</em> for matters related to licensing</li>
-            <li><em>repository</em> for matters related to the maven repositories</li>
             <li><em>infrastructure-issues</em> for matters related to </li>
         </ul>
     </section>
@@ -829,21 +792,6 @@ So typically, the release manager needs 
 A release is a good time to concentrate energy on documentation.
     		</p>
     	</section>
-        <section id='best-practice-jars'><title>Jars</title>
-            <ul>
-                <li><code>META-INF</code>
-                    <ul>
-                        <li>
-    Must include <a href='#license'>LICENSE</a> and <a href='#NOTICE'>NOTICE</a>.

-    Note <a href='#distributing-jars'>this</a>
-                        </li>
-                        <li>
-    Should include a standards compliant MANIFEST. Note <a href='#jar-manifest'>this</a>.
-                        </li>
-                    </ul>
-                </li>
-            </ul>
-        </section>
         <section id='best-practice-naming'><title>Artifact Naming</title>
         	<p>
             TODO: should include apache in the title (gives trademark protection against
different jars 
@@ -1046,14 +994,6 @@ into the current directory). The directo
 the standard naming convention. apache-foo.tar.gz should unpack to the apache-foo
 directory.
             </p>
-            <p>
-Note (TODO link) that there are known compatibility issues when using certain tar programs.

-(TODO Saris verses GNU tar)
-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 package as a bz2 archive.
-            </p>
         </section>
         <section id='best-practice-source-build'><title>Source Package Build</title>
         	<p>
@@ -1064,9 +1004,6 @@ Source packages should contain easy inst
 The source package should build from instructions contained. 
 TODO: best practices for instructing users about building the project.
             </p>
-            <p>
-Build instructions should give supported version numbers for build tools (for example, maven
and ant).
-            </p>
         </section>
         <section id='best-practice-dependencies'><title>Dependencies</title>

         	<p>
@@ -1099,9 +1036,6 @@ dependencies.
 TODO: ASF policy compliance
 TODO: project policy - explicit policy should be written down
             </p>
-            <p>
-TODO: Discussion on the merits of distributing dependent jars. This should be a link to the
notes section
-            </p>
         </section>
         
         <section id='best-practice-notice'><title>NOTICE files</title>
@@ -1195,8 +1129,7 @@ As well as libraries, projects often hav
 Most languages have different versions, and it is important that the versions
 of a language upon which a project will build and 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. 
+are a typical location for this information.
         	</p>
         	<p>
 It is important to review all library dependencies as part of the release process
@@ -1308,26 +1241,6 @@ Please remember to delete release candid
  isolated installation to store the code signing key and to sign releases.
         	</p>
         </section>
-        <section id='best-practice-maven'><title>Maven</title>
-        	<p>
-<a href='http://maven.apache.org'>Apache Maven</a> is a tool used by many podlings.
-TODO: improve preamble
-        	</p>
-        	<p>
-It is best to use the <code>groupId</code> and <code>artifactId</code>
that will
-be used upon graduation. The version should include <code>incubating</code> 
-(or <code>incubator</code>) to ensure that the artifacts created comply with
Incubator
-<a href="&root-path;/incubation/Incubation_Policy.html#Releases">release policy</a>.
-        	</p>
-        	<p>
-For example
-        	</p>
-<code><pre>
-	&lt;groupId&gt;org.apache.wicket&lt;/groupid&gt;
-	&lt;artifactId&gt;wicket-parent&lt;/artifactId&gt;
-	&lt;version&gt;1.3-incubating-SNAPSHOT&lt;/version&gt;
-</pre></code>
-        </section>
     </section>
     <section id='notes'><title>Notes</title>
         <section id='notes-on-licenses'><title>License Issues</title> 
@@ -1347,41 +1260,6 @@ TODO: complete content
             DISCLAIMER. It is recommended that it is not included in NOTICES
             </p>
         </section>
-        <section id='distributing-jars'><title>Distributing Jars</title>
-            <p>
-            TODO: link to infrastructure
-            </p>
-            <p>
-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 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

-either with Ant or Maven. TODO: move examples here from jakarta commons releases.
-            </p>
-        </section>
-        <section id='jar-manifest'><title>Jar MANIFEST</title>
-            <p>
-TODO
-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
-            </p>
-            <p>
-Maven 1 produces a minimal MANIFEST. This should be augmented with the 
-recommended by adding appropriate 
-<a href='http://maven.apache.org/maven-1.x/plugins/jar/properties.html'>properties</a>
-to the <code>project.properties</code> file.
-            </p>
-            <p>
-Maven 2 produces a much better manifest provided that the POM is reasonably full.
-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 recommended entries.
-            </p>
-        </section>
         <section id='best-practice-release-candidate'><title>Release Candidates</title>
               <p>
 There are two distinct approaches: <a href='#glossary-release-candidate'>release candidate</a>
and TODO.  
@@ -1559,19 +1437,6 @@ This may be included by reference to the
 but (for the benefit of those that don't read document) should be mentioned.
 			</p>
         </section>
-        <section id='note-compatibility-checkers'><title>Compatibility Checkers</title>
-			<p>
-Some tools used by Apache projects:
-			</p>
-			<ul>
-				<li>Java
-					<ul>
-						<li><a href='http://clirr.sourceforge.net//'>Clirr</a> works on binaries</li>
-						<li><a href='http://jdiff.sourceforge.net/'>JDiff</a> uses sources</li>
-					</ul>
-				</li>
-			</ul>
-        </section>
         <section id='notes-change-log'><title>Change Logs</title>
         	<p>
 TODO: should this be in best practices
@@ -1581,7 +1446,6 @@ TODO: add examples
 A change log indicates the changes made to the project since the last release.
 Some projects include a change log in the release notes documents.
 Others use a separate document often called <code>ChangeLog</code>.
-Maven can be used to generate a change log as part of the project documentation.
         	</p>
         	<p>
 Change logs can be created in various ways. Some project ask committers to fill
@@ -1648,43 +1512,6 @@ If not then consider adding a NOTE or a 
 than a license header.
         	</p>
         </section>
-        <section id='notes-on-java-version'><title>On Java Versions</title>
-        	<p>
-Indicating supported versions for dependencies is 
-<a href='#best-practice-dependencies'>important</a>. The minimum 
-(and - where appropriate - maximum)  Java version need to be clearly documented
-in the release. This information should be included in a README or the RELEASE NOTES.
-        	</p>
-        	<p>
- Users often expect the minimum version supported to be the one listed in the MANIFEST.
- There are also good reasons for releases to be compiled with the minimum version 
- of Java supported by the release. This is the easiest way to ensure that the release
- will work as expected on that version. This will ensure that the version in the MANIFEST
- is as expected. 
- 			</p>
- 			<p>
-If the version in the MANIFEST cannot reflect the minimum support version (see below) 
-then it is recommended that the flowing additional entries are added to MANIFEST.
- 			</p>
- 			<p>
-The usual reason for need to use a more modern Java version is to support
-optional classes which require features present only in the new version.
-			</p>
-			<p>
-The approach which requires the least configuration is to adopt a split compilation
-strategy. The release manager installs two separate Java versions. The build
-script supports optional parameterization allowing the optional code to be compiled with

-a second JSDK. It is recommended that the build scrip includes clear indications
-that a second JSDK has been detected.
- 			</p>
- 			<p>
-The alternative is to correctly configure a more modern JSDK to compile code
-which will function correctly on another JRE. This means TODO: javac settings through 
-Ant. This is not sufficient. Unfortunately the source also need to be compiled against
-the appropriate version of the Java API. TODO: check where the jar has to be exactly
-placed.
-        	</p>
-        </section>
         <section id='notes-on-export-regulations'><title>On Export Regulations</title>
         	<p>
 TODO preamble TODO link to legal
@@ -1702,9 +1529,7 @@ It is convenient for users and more cons
 for the <code>zip</code> and <code>LF</code> for the <code>tar.gz</code>).
         	</p>
             <p>
-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>.
+Source packages can use <code>svn export --native-es</code>.
             </p>
         </section>
         <section id='notes-press-releases'><title>On Press Releases</title>
@@ -1717,19 +1542,6 @@ press interest in a release then please 
 TODO: link to public relations committee
         	</p>
         </section>
-        <section id='notes-on-signing-jars'><title>On Signing Jars</title>
-        	<p>
-Java includes a standard mechanism for signing jars. Apache uses digital
-signatures to protect releases. TODO: reconsider this section.
-        	</p>
-        	<p>
-Though there is no rule against issuing signed jars, project should educate
-themselves about the potentially negative consequences of doing so.
-Classloaders treat signed jars differently. In particular, packages are 
-sealed against modification. Open source encourages modification. 
-TODO: rephrase and check
-        	</p>
-        </section>
         <section id='notes-license-headers'><title>On License Headers</title>
             <p>
             TODO: links into legal documentation. discuss issues about which files need to
apply.
@@ -1791,12 +1603,6 @@ in the directory containing license info
 TODO: importance of accurately reporting to the user the state of an implementation
 TODO: importance of complying with the reporting requirements set by the standard creator
         	</p>
-        	<section id='notes-jsr'><title>JSRs</title>
-        		<p>
-TODO: write up http://marc.theaimsgroup.com/?l=incubator-general&amp;m=116577422312412&amp;w=2
-TODO: then check with Geir
-        		</p>
-        	</section>
         </section>
         <section id='note-license-and-notice'><title>Understanding Content For
NOTICE and LICENSE</title>
         	<p>
@@ -1961,22 +1767,6 @@ This allows people to check their votes 
  release candidate).
         	</p>
         </section>
-        <section id='notes-release-candidate-java'><title>On Java Release Candidates</title>
-			<p>
-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 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.
-			</p>
-        </section>
         <section id='notes-on-gnu-tar'><title>GNU Tar Known Incompatibilities</title>
         	<p>
 Typically, applications used to create <code>tar.gz</code> files are based on
@@ -2073,14 +1863,6 @@ are only intended for people participati
         	TODO: link to foundation docs
         	</p>
         </section>
-        <section id='glossary-manifest'><title>Jar MANIFEST</title>
-        	<p>
-Meta data, enumerating the contents of the Jar, associated with the Java Jar format.
-        	</p>
-            <p>
-            TODO link to sun documentation
-            </p>
-        </section>
          <section id='glossary-license-header'><title>License Header</title>
          	<p>
 Text referring to the license for a file (as opposed to the license text).



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


Mime
View raw message