db-jdo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mad...@apache.org
Subject svn commit: r1195086 - in /db/jdo: HowToReleaseJDO.html bin/sign-directory branches/3.0.1/project.properties
Date Sun, 30 Oct 2011 01:51:29 GMT
Author: madams
Date: Sun Oct 30 01:51:28 2011
New Revision: 1195086

URL: http://svn.apache.org/viewvc?rev=1195086&view=rev
Log:
checking in what I have done so far

Modified:
    db/jdo/HowToReleaseJDO.html
    db/jdo/bin/sign-directory
    db/jdo/branches/3.0.1/project.properties

Modified: db/jdo/HowToReleaseJDO.html
URL: http://svn.apache.org/viewvc/db/jdo/HowToReleaseJDO.html?rev=1195086&r1=1195085&r2=1195086&view=diff
==============================================================================
--- db/jdo/HowToReleaseJDO.html (original)
+++ db/jdo/HowToReleaseJDO.html Sun Oct 30 01:51:28 2011
@@ -1,312 +1,295 @@
-<!--
-  Licensed to the Apache Software Foundation (ASF) under one or more
-  contributor license agreements.  See the NOTICE file distributed with
-  this work for additional information regarding copyright ownership.
-  The ASF licenses this file to You under the Apache License, Version 2.0
-  (the "License"); you may not use this file except in compliance with
-  the License.  You may obtain a copy of the License at
-
-      http://www.apache.org/licenses/LICENSE-2.0
-
-  Unless required by applicable law or agreed to in writing, software
-  distributed under the License is distributed on an "AS IS" BASIS,
-  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-  See the License for the specific language governing permissions and
-  limitations under the License.
-  -->
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
-	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
-	<TITLE>JDO Release Process</TITLE>
-</HEAD>
-<BODY LANG="en-US">
-<UL>
-    <LI><a href="#procoverview">Overview of the process</a></LI>
-    <LI><a href="#procdetail">Detailed process steps</a></LI>
-    <LI><a href="#site">Site updates</a></LI>
-    <LI><a href="#postrelease">Post release modifications and documentation</a></LI>
-</UL>
-<h1>How to Release an Apache JDO Distribution</h1>
-<p>
-A distribution of JDO is built from a branch of svn. It is copied into a 
-release directory, from which it is staged and tested prior to release. 
-Once released, it is propagated to mirror servers around the world.
-</p><p>
-The process is performed by a release manager with cooperation from testers
-in the community.
-</p>
-<a name="procoverview"></a>
-<h2>Overview of the process</h2>
-<p>
-The community first decides on the name of the release. The format
-of the name is <i>spec-number</i>.<i>major</i>.<i>minor</i>.
-The spec-number is either 1 for JDO 1 or 2 for JDO 2.
-The major number would change for a specification revision
-approved by the JCP via specification maintenance review. The minor number
-can be used for changes that do not need a maintenance review and
-do not change the interfaces.
-A trailing <i>minor</i> number
-with a zero value is right trimmed, so there might be a 2.0.1 but not a 2.0.0.
-</p><p>
-Interim releases prior to final release are identified by a suffix on the 
-release number. Common suffixes include: -alpha, -beta, -beta2, -rc1, -rc2. 
-Generally, the suffixes are part of the release plan, and the contents
-of each suffix release are agreed by the community. There might be
-significant changes in functionality between the suffix releases. Each
-suffix release goes through the process documented here.
-</p><p>
-The release manager makes a branch from the trunk (for a major release) or
-from another branch (for a minor release) to create a branch with the 
-source of the distribution.
-</p><p>
-The release manager modifies the branch to change dependencies from SNAPSHOT
-to projects in the release.
-</p><p>
-The release manager builds and tests the components of the release and
-checks the release build into svn.
-</p><p>
-The release manager publishes the release on a staging area of the apache
-server and calls for the community to test the release.
-</p><p>
-The community tests the release. If necessary, cycle until all issues are
-resolved.
-</p><p>
-The release manager calls for a vote to release by sending a message to the
-community and forwarding the message to the pmc.
-</p><p>
-The community votes on the release. If necessary, cycle until issues are 
-resolved.
-</p><p>
-The release manager notifies the pmc of the successful vote outcome.
-Note that a successful vote includes three +1 votes from PMC members.
-</p><p>
-The release manager distributes the release, which is then copied to mirror
-sites worldwide.
-</p><p>
-The release manager notifies the worldwide community of the availability
-of the release.
-</p><p>
-The release manager updates the JDO web sites (http://db.apache.org/jdo/index.html, http://java.sun.com/jdo/).
-</p><p>
-If bugs are found or test challenges are sustained after the release is approved and distributed,
the release
-manager creates a new branch to address the bugs found.
-</p>
-<a name="procdetail"></a>
-<h2>Detailed process steps</h2>
-<p>
-<OL>
-    <LI>Create a branch from the trunk and increment the spec or major number.
-    For example, create a 2.2 branch from the trunk.
-    <pre>
-cd jdo
-svn copy https://svn.apache.org/repos/asf/db/jdo/trunk \
-https://svn.apache.org/repos/asf/db/jdo/branches/2.2
-</pre>
-    </LI>
-    <LI>In trunk, update version numbers 
-        in the following files in preparation for the next release:
-        <DL>
-            <DT>trunk/project.properties
-            <DD>Change value of currentVersion
-            <DT>trunk/README.html
-            <DD>File names and version references in the Overview section
-            <DT>trunk/JDO20.MF, api2/API2.MF, api2-legacy/API2.MF
-            <DD>Update Specification-Version and Bundle-Version
-            <DT>trunk/api2/project.xml
-            <DD>Update currentVersion
-            <DT>trunk/tck2/RunRules.html
-            <DD>Update version number
-        </DL>
-    </LI>
-
-    <LI>In the release branch,
-        remove the projects and files that are not being released.
-<pre>
-pushd branches/2.n
-svn rm api11 btree fostore20 query20 runtime20 ri11 tck11 JDO11.MF 
-svn commit -m "Remove projects and files that are not being released"
-</pre>
-    </LI>
-
-    <LI>If needed, update the dependency to DataNucleus in the tck2 project.xml.</LI>
-
-    <LI>If needed, apply patches from the trunk or branches to the new branch.</LI>
-
-<a name="version"></a>
-    <LI>Update version numbers where necessary in projects to be released, if 
-    these changes haven't been made previously. Check the following files:
-        <DL>
-            <DT>branches/<version>/project.properties
-            <DD>Change value of currentVersion
-            <DT>branches/<version>/README.html
-            <DD>File names and version references in the Overview section
-            <DT>branches/<version>/JDO20.MF, api2/API2.MF, api2-legacy/API2.MF
-            <DD>Update Specification-Version and Bundle-Version
-            <DT>branches/<version>api2/project.xml
-            <DD>Update currentVersion
-            <DT>trunk/tck2/RunRules.html
-            <DD>Update version number and release date
-        </DL>
-    </LI>
-
-    <LI>Update the details in branches/<version>/api2/m2_repo_maven_metadata.xml
-    to include the version being released.</LI>
-
-    <LI>Copy the JNDI implementation jars (providerutil.jar and fscontext.jar) 
-    to the branch lib/ext directory. This is needed to test the tck before 
-    distributing it.
-<pre>
-cp trunk/lib/ext/* branches/2.n/lib/ext
-</pre>
-    <b>Do not check these in to SVN</b>
-    </LI>
-
-    <LI>Build the distribution. This creates .gz files and .zip files in the 
-    target/distributions directory of each project. It also creates the .jar
-    and .pom files.  It then copies the release artifacts to the 
-    releases/2.n/dist directory. The dist directory is in a format that
-    can be copied directly to the apache dist directory for distribution.
-    It contains two subdirectories; db contains downloadable artifacts and
-    java-repository contains artifacts that are automatically pulled to maven
-    repositories.
-    <I>Note: Failure possibly due to insufficient heap space was fixed by
-       setting the environment variable 
-       MAVEN_OPTS="-Xmx1024m -Xms1024m -XX:MaxPermSize=512m"</I>
-<pre>
-pushd branches/2.n
-maven tck2.default
-maven tck2.dist
-popd
-</pre>
-    </LI>
-
-    <LI>Test the release in the branch.
-<pre>
-pushd branches/2.n/tck20
-maven installSchema
-maven runtck.jdori
-popd
-</pre>
-    Also run RAT on the release: http://code.google.com/p/arat/
-    </LI>
-
-    <LI>Sign the artifacts. You must have a gpg key in order to perform this
-    step. The sign-directory script is checked into jdo/bin.
-    Edit this script to refer to your own environment (do not check it in).
-<pre>
-bin/sign-directory releases/2.n/dist/jdo2.<i>n</i>-rc<i>m</i>
-</pre>
-    </LI>
-
-    <LI>Push the artifacts to the staging area on the apache server.
-<pre>
-scp -r releases/2.n/dist <i>username</i>@people.apache.org:~/public_html
-</pre>
-    </LI>
-
-    <LI>ssh to people.apache.org and change to the public_html directory.
-    Make sure that all the copied directories have executable permission.
-    If not change the permission for each:
-<pre>
-chmod a+x <i>dir</i>
-</pre>
-    </LI>
-
-    <LI>Test the release from the staging area.</LI>
-
-    <LI>Send an announcement to test the release to the jdo-dev@db.apache.org alias.
If problems are found, fix and repeat.</LI>
-
-    <LI>Send an announcement to vote on the release to the 
-    jdo-dev@db.apache.org alias. The message subject line contains [VOTE].
-    Forward the [VOTE] message to private@db.apache.org. Iterate until you 
-    get a successful vote. Mail the results of the vote to 
-    jdo-dev@db.apache.org, cc: general@db.apache.org, and include 
-    [VOTE] [RESULTS] in the subject line.</LI>
-
-    <LI>After testing and voting is complete, push the artifacts to the 
-    Apache web. Mirrors automatically pick up Apache artifacts from 
-    /www/www.apache.org/dist.
-<pre>
-ssh people.apache.org
-cp -r public_html/jdo<i>version</i>/dist/db /www/www.apache.org/dist
-cp -r public_html/jdo<i>version</i>/dist/m1-ibiblio-rsync-repository/* /www/people.apache.org/repo/m1-ibiblio-rsync-repository
-cp -r public_html/jdo<i>version</i>/dist/m2-ibiblio-rsync-repository/* /www/people.apache.org/repo/m2-ibiblio-rsync-repository
-</pre>
-    NOTE!! Be sure that there is no slash at the end of the directory you are copying from;
otherwise the files will be put in the wrong target directory.
-    </LI>
-
-    <LI>Ask one of the Apache repository folks to push the m1-ibiblio-rsync-repository
since this repository is no longer automatically synchronized. Send a message to repository@apache.org
to push the new artifacts.
-    </LI>
-
-    <LI>Check the distribution into svn
-<pre>
-svn add releases/2.n
-svn commit -m "Create release 2.n" releases/2.n
-</pre>
-    </LI>
-
-    <LI>To get the Maven2 repo populated with Maven1 jars ask 
-        repository@apache.org to push the release</LI>
-
-    <LI>If the release is a bug fix release to a maintenance release, update 
-    README.txt in the parent branch, adding the following line: 
-    "This release has been deprecated. Please use version 2.x.y.", with a link
-    to the svn web interface for that version.</LI>
-
-    <LI>After updating the site (below), announce the release to the Apache
-    community via email to announce@apache.org
-    This must be sent from an @apache.org email address.
-    *** Be aware the by sending to this address you will be bombarded
-        with piles of emails from people with "I'm out of the Office"
-        as if you really cared ***</LI>
-</OL>
-
-<a name="site"></a>
-<h2>Site updates</h2>
-<OL>
-<LI>Update the Apache JDO web site to point the downloads page to the release.
-<OL>
-    <LI>In site/xdocs/releases create release-2.n.xml. Edit the release numbers and
the link to the release notes. You will need to change the '&'s in the URL
-    to "&amp;amp;"</LI>
-    <LI>In site/xdocs/releases create release-2.n.cgi.  The .cgi file contents are
identical to the other .cgi files in the release directory; only the file name differs.</LI>
-    <LI>Edit site/xdocs/downloads.xml to link to the new release page .cgi document.</LI>
-    <LI>Build and test as described in the site/HOWTO document. 
-    Note that the cgi page will not be active until it is on the server,
-    so can't really be tested.</LI>
-    <LI>Add the new files to the subversion repository.
-    <pre>
-svn add xdocs/releases/release-2.n.html 
-svn add docs/releases/release-2.n.html 
-svn add xocs/releases/release-2.n.cgi 
-svn add docs/releases/release-2.n.cgi 
-    </pre></LI>
-    <LI>Set the svn properties svn:eol-style to native and svn:executable to true for
the .cgi files.</LI>
-</OL>
-</LI>
-<LI>Change the link to RunRules on the <a href="http://db.apache.org/jdo/tck.html">TCK</a>
page to link to the RunRules.html file of the latest release.</LI>
-<LI>Update the news list on the site home page to announce the new release.</LI>
-<LI>Add the javadoc for the release to the site.
-<OL>
-    <LI>Make a new directory under site/docs for the release, e.g. api2.1. We'll call
it <i>docsdir</i>.</LI>
-    <LI>Copy the apidocs directory from the release branch target/docs directory to
<i>docsdir</i>.</LI>
-    <LI>Make a zip file of the apidocs tree and put it in <i>docsdir</i>.</LI>
-    <LI>Do svn add on <i>docsdir</i>.</LI>
-    <LI>Edit xdocs/javadoc.xml and add links to the new javadoc.</LI>
-</OL>
-</LI>
-<LI> Build and test. Follow the instructions in site/HOWTO to push the site changes
to the Apache web site.</LI>
-</OL>
-<a name="postrelease"></a>
-<h2>Post release modifications and documentation</h2>
-Follow this procedure if a significant bug is found or if the TCK must be modified because
a test challenge is found to be valid.
-<OL>
-    <LI>Create a new branch from the release branch, incrementing the minor number.
 For example, create a branch named 2.1.1, from the 2.1 branch.
-    </LI><LI>Merge bug fixes or other modifications into the new branch.
-    </LI><LI> In the new branch, modify trunk/README.txt to include a section
on bug fixes since the 2.1 release, and to suggest checking out the source from a bug-fix
branch to get the fixes listed.
-    </LI><LI> Link to this README in the web interface to svn from the .cgi download
page and from http://db.apache.org/jdo/tck.html.
-</LI>
-</OL>
-</BODY>
-</HTML>
-
+<!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed with
+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License, Version 2.0
+  (the "License"); you may not use this file except in compliance with
+  the License.  You may obtain a copy of the License at
+
+      http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an "AS IS" BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+  See the License for the specific language governing permissions and
+  limitations under the License.
+  -->
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+<html>
+  <head>
+    <meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
+    <title>JDO Release Process</title>
+  </head>
+  <body lang="en-US">
+    <ul>
+      <li><a href="#procoverview">Overview of the process</a></li>
+      <li><a href="#procdetail">Detailed process steps</a></li>
+      <li><a href="#site">Site updates</a></li>
+      <li><a href="#postrelease">Post release modifications and
+          documentation</a></li>
+    </ul>
+    <h1>How to Release an Apache JDO Distribution</h1>
+    <p> A distribution of JDO is built from a branch of svn. It is
+      copied into a release directory, from which it is staged and
+      tested prior to release. Once released, it is propagated to mirror
+      servers around the world. </p>
+    <p> The process is performed by a release manager with cooperation
+      from testers in the community. </p>
+    <a name="procoverview"></a>
+    <h2>Overview of the process</h2>
+    <p> The community first decides on the name of the release. The
+      format of the name is <i>spec-number</i>.<i>major</i>.<i>minor</i>.
+      A trailing <i>minor</i> number with a zero value is right
+      trimmed, so there might be a 2.0.1 but not a 2.0.0. </p>
+    <p> Interim releases prior to final release are identified by a
+      suffix on the release number. Common suffixes include: -alpha,
+      -beta, -beta2, -rc1, -rc2. Generally, the suffixes are part of the
+      release plan, and the contents of each suffix release are agreed
+      by the community. There might be significant changes in
+      functionality between the suffix releases. Each suffix release
+      goes through the process documented here. </p>
+    <p> The release manager makes a branch from the trunk (for a major
+      release) or from another branch (for a minor release) to create a
+      branch with the source of the distribution. </p>
+    <p> The release manager modifies the branch to change dependencies
+      from SNAPSHOT to projects in the release. </p>
+    <p> The release manager builds and tests the components of the
+      release and checks the release build into svn. </p>
+    <p> The release manager publishes the release on a staging area of
+      the apache server and calls for the community to test the release.
+    </p>
+    <p> The community tests the release. If necessary, cycle until all
+      issues are resolved. </p>
+    <p> The release manager calls for a vote to release by sending a
+      message to the community and forwarding the message to the pmc. </p>
+    <p> The community votes on the release. If necessary, cycle until
+      issues are resolved. </p>
+    <p> The release manager notifies the pmc of the successful vote
+      outcome. Note that a successful vote includes three +1 votes from
+      PMC members. </p>
+    <p> The release manager distributes the release, which is then
+      copied to mirror sites worldwide. </p>
+    <p> The release manager notifies the worldwide community of the
+      availability of the release. </p>
+    <p> The release manager updates the JDO web sites
+      (http://db.apache.org/jdo/index.html, http://java.sun.com/jdo/). </p>
+    <p> If bugs are found or test challenges are sustained after the
+      release is approved and distributed, the release manager creates a
+      new branch to address the bugs found. </p>
+    <a name="procdetail"></a>
+    <h2>Detailed process steps</h2>
+    <p> </p>
+    <ol>
+      <li>Create a branch from the trunk and increment the spec or major
+        number. For example, create a 3.1 branch from the trunk.
+        <pre>cd jdo
+svn copy https://svn.apache.org/repos/asf/db/jdo/trunk \
+https://svn.apache.org/repos/asf/db/jdo/branches/3.1
+</pre>
+      </li>
+      <li>In trunk, update version numbers in the following files in
+        preparation for the next release:
+        <dl>
+          <dt>trunk/project.properties </dt>
+          <dd>Change value of currentVersion </dd>
+          <dt>trunk/README.html </dt>
+          <dd>File names and version references in the Overview section
+          </dd>
+          <dt>trunk/JDO3.MF</dt>
+          <dd>Update Specification-Version and Bundle-Version </dd>
+          <dt>trunk/api/project.xml </dt>
+          <dd>Update currentVersion </dd>
+          <dt>trunk/tck/RunRules.html </dt>
+          <dd>Update version number </dd>
+        </dl>
+      </li>
+      <li>In the pending release branch (jdo/branches/xxx), remove the
+        projects and files that are not being released.
+        <pre>pushd branches/2.n
+svn rm api11 btree fostore20 query20 runtime20 ri11 tck11 JDO11.MF 
+svn commit -m "Remove projects and files that are not being released"
+</pre>
+      </li>
+      <li>If needed, update the dependency to the RI, DataNucleus, in
+        the tck project.xml.</li>
+      <li>If needed, apply patches from the trunk or branches to the new
+        branch.</li>
+      <a name="version"></a>
+      <li>Update version numbers where necessary in projects to be
+        released, if these changes haven't been made previously. Check
+        the following files:
+        <dl>
+          <dt>branches/<version>/project.properties </version></dt>
+          <dd>Change value of currentVersion </dd>
+          <dt>branches/<version>/README.html </version></dt>
+          <dd>File names and version references in the Overview section
+          </dd>
+          <dt>branches/<version>/JDO30.MF</version></dt>
+          <dd>Update Specification-Version and Bundle-Version </dd>
+          <dt>branches/<version>api/project.xml </version></dt>
+          <dd>Update currentVersion </dd>
+          <dt>trunk/tck/RunRules.html </dt>
+          <dd>Update version number and release date </dd>
+        </dl>
+      </li>
+      <li>Update the details in branches/<version>/api/m2_repo_maven_metadata.xml
+
+
+          to include the version being released.</version></li>
+      <li>Copy the JNDI implementation jars (providerutil.jar and
+        fscontext.jar) to the branch lib/ext directory. This is needed
+        to test the tck before distributing it.<b><br>
+          Do not check these in to SVN</b> </li>
+      <li>Manually install vdoclet:qdox:current:jar artifacts to your
+        local Maven 1 repository.&nbsp; It can be found at <a
+          href="http://repo1.maven.org/maven2/vdoclet/qdox/current/">http://repo1.maven.org/maven2/vdoclet/qdox/current/</a>.&nbsp;
+        Make sure to download qdox-current.jar to
+        ~/.maven/repository/vdoclet/jars.<br>
+      </li>
+      <li>Build the distribution. This creates .gz files and .zip files
+        in the target/distributions directory of each project. It also
+        creates the .jar and .pom files. It then copies the release
+        artifacts to the releases/2.n/dist directory. The dist directory
+        is in a format that can be copied directly to the apache dist
+        directory for distribution. It contains two subdirectories; db
+        contains downloadable artifacts and java-repository contains
+        artifacts that are automatically pulled to maven repositories. <i>Note:
+
+          Failure possibly due to insufficient heap space was fixed by
+          setting the environment variable MAVEN_OPTS="-Xmx1024m
+          -Xms1024m -XX:MaxPermSize=512m"</i>
+        <pre>pushd branches/3.n
+maven jdo3.build
+maven jdo3.dist
+popd
+</pre>
+      </li>
+      <li>Run RAT, which is at <a
+          href="http://incubator.apache.org/rat/">http://incubator.apache.org/rat/</a>,
+        on the release. </li>
+      <li>Sign the artifacts. You must have a gpg key in order to
+        perform this step. The sign-directory script is checked into
+        jdo/bin. Edit this script to refer to your own environment (do
+        not check it in). If you're on Windows, your best bet is to run
+        this script via a cygwin bash shell.<br>
+        <pre>bin/sign-directory releases/3.n/dist/
+</pre>
+      </li>
+      <li>Push the artifacts to the staging area on the apache server.
+        <pre>scp -r releases/2.n/dist <i>username</i>@people.apache.org:~/public_html
+</pre>
+      </li>
+      <li>ssh to people.apache.org and change to the public_html
+        directory. Make sure that all the copied directories have
+        executable permission. If not change the permission for each:
+        <pre>chmod a+x <i>dir</i>
+</pre>
+      </li>
+      <li>Test the release from the staging area.</li>
+      <li>Send an announcement to test the release to the
+        jdo-dev@db.apache.org alias. If problems are found, fix and
+        repeat.</li>
+      <li>Send an announcement to vote on the release to the
+        jdo-dev@db.apache.org alias. The message subject line contains
+        [VOTE]. Forward the [VOTE] message to private@db.apache.org.
+        Iterate until you get a successful vote. Mail the results of the
+        vote to jdo-dev@db.apache.org, cc: general@db.apache.org, and
+        include [VOTE] [RESULTS] in the subject line.</li>
+      <li>After testing and voting is complete, push the artifacts to
+        the Apache web. Mirrors automatically pick up Apache artifacts
+        from /www/www.apache.org/dist.
+        <pre>ssh people.apache.org
+cp -r public_html/jdo<i>version</i>/dist/db /www/www.apache.org/dist
+cp -r public_html/jdo<i>version</i>/dist/m1-ibiblio-rsync-repository/* /www/people.apache.org/repo/m1-ibiblio-rsync-repository
+cp -r public_html/jdo<i>version</i>/dist/m2-ibiblio-rsync-repository/* /www/people.apache.org/repo/m2-ibiblio-rsync-repository
+</pre>
+        NOTE!! Be sure that there is no slash at the end of the
+        directory you are copying from; otherwise the files will be put
+        in the wrong target directory. </li>
+      <li>Ask one of the Apache repository folks to push the
+        m1-ibiblio-rsync-repository since this repository is no longer
+        automatically synchronized. Send a message to
+        repository@apache.org to push the new artifacts. </li>
+      <li>Check the distribution into svn
+        <pre>svn add releases/2.n
+svn commit -m "Create release 2.n" releases/2.n
+</pre>
+      </li>
+      <li>To get the Maven2 repo populated with Maven1 jars ask
+        repository@apache.org to push the release</li>
+      <li>If the release is a bug fix release to a maintenance release,
+        update README.txt in the parent branch, adding the following
+        line: "This release has been deprecated. Please use version
+        2.x.y.", with a link to the svn web interface for that version.</li>
+      <li>After updating the site (below), announce the release to the
+        Apache community via email to announce@apache.org This must be
+        sent from an @apache.org email address. *** Be aware the by
+        sending to this address you will be bombarded with piles of
+        emails from people with "I'm out of the Office" as if you really
+        cared ***</li>
+    </ol>
+    <a name="site"></a>
+    <h2>Site updates</h2>
+    <ol>
+      <li>Update the Apache JDO web site to point the downloads page to
+        the release.
+        <ol>
+          <li>In site/xdocs/releases create release-2.n.xml. Edit the
+            release numbers and the link to the release notes. You will
+            need to change the '&amp;'s in the URL to "&amp;amp;"</li>
+          <li>In site/xdocs/releases create release-2.n.cgi. The .cgi
+            file contents are identical to the other .cgi files in the
+            release directory; only the file name differs.</li>
+          <li>Edit site/xdocs/downloads.xml to link to the new release
+            page .cgi document.</li>
+          <li>Build and test as described in the site/HOWTO document.
+            Note that the cgi page will not be active until it is on the
+            server, so can't really be tested.</li>
+          <li>Add the new files to the subversion repository.
+            <pre>svn add xdocs/releases/release-2.n.html 
+svn add docs/releases/release-2.n.html 
+svn add xocs/releases/release-2.n.cgi 
+svn add docs/releases/release-2.n.cgi 
+    </pre>
+          </li>
+          <li>Set the svn properties svn:eol-style to native and
+            svn:executable to true for the .cgi files.</li>
+        </ol>
+      </li>
+      <li>Change the link to RunRules on the <a
+          href="http://db.apache.org/jdo/tck.html">TCK</a> page to link
+        to the RunRules.html file of the latest release.</li>
+      <li>Update the news list on the site home page to announce the new
+        release.</li>
+      <li>Add the javadoc for the release to the site.
+        <ol>
+          <li>Make a new directory under site/docs for the release, e.g.
+            api2.1. We'll call it <i>docsdir</i>.</li>
+          <li>Copy the apidocs directory from the release branch
+            target/docs directory to <i>docsdir</i>.</li>
+          <li>Make a zip file of the apidocs tree and put it in <i>docsdir</i>.</li>
+          <li>Do svn add on <i>docsdir</i>.</li>
+          <li>Edit xdocs/javadoc.xml and add links to the new javadoc.</li>
+        </ol>
+      </li>
+      <li> Build and test. Follow the instructions in site/HOWTO to push
+        the site changes to the Apache web site.</li>
+    </ol>
+    <a name="postrelease"></a>
+    <h2>Post release modifications and documentation</h2>
+    Follow this procedure if a significant bug is found or if the TCK
+    must be modified because a test challenge is found to be valid.
+    <ol>
+      <li>Create a new branch from the release branch, incrementing the
+        minor number. For example, create a branch named 2.1.1, from the
+        2.1 branch. </li>
+      <li>Merge bug fixes or other modifications into the new branch. </li>
+      <li> In the new branch, modify trunk/README.txt to include a
+        section on bug fixes since the 2.1 release, and to suggest
+        checking out the source from a bug-fix branch to get the fixes
+        listed. </li>
+      <li> Link to this README in the web interface to svn from the .cgi
+        download page and from http://db.apache.org/jdo/tck.html. </li>
+    </ol>
+  </body>
+</html>

Modified: db/jdo/bin/sign-directory
URL: http://svn.apache.org/viewvc/db/jdo/bin/sign-directory?rev=1195086&r1=1195085&r2=1195086&view=diff
==============================================================================
--- db/jdo/bin/sign-directory (original)
+++ db/jdo/bin/sign-directory Sun Oct 30 01:51:28 2011
@@ -7,15 +7,15 @@ GPG_CMD=gpg
 GPG_OPTS="--armor --detach-sign"
 
 # find
-#FIND=find
-FIND=c:/cygwin/bin/find
+FIND=find
+#FIND=c:/cygwin/bin/find
 
 # md5
 # Use this line for linux
-#MD5_CMD=md5sum
+MD5_CMD=md5sum
 # Use these two lines for http://www.fourmilab.ch/md5/
-MD5_CMD=md5
-MD5_OPTS="-l -n"
+#MD5_CMD=md5
+#MD5_OPTS="-l -n"
 
 # Verify that there is a directory parameter
 if [ $# -eq 0 ]

Modified: db/jdo/branches/3.0.1/project.properties
URL: http://svn.apache.org/viewvc/db/jdo/branches/3.0.1/project.properties?rev=1195086&r1=1195085&r2=1195086&view=diff
==============================================================================
--- db/jdo/branches/3.0.1/project.properties (original)
+++ db/jdo/branches/3.0.1/project.properties Sun Oct 30 01:51:28 2011
@@ -42,12 +42,6 @@ maven.javadoc.windowtitle = ${pom.name} 
 # project lists
 #   please note, the project lists must not include blanks
 jdo3.projects=api/project.xml,tck/project.xml
-jdo11.projects=api11/project.xml,btree/project.xml,ri11/project.xml,tck11/project.xml
-jdo2.projects=api2/project.xml,util20/project.xml,model20/project.xml,enhancer20/project.xml,\
-runtime20/project.xml,query20/project.xml,btree/project.xml,fostore20/project.xml,\
-tck2/project.xml
-tck2.projects=api2/project.xml,util20/project.xml,model20/project.xml,enhancer20/project.xml,tck2/project.xml
-fostore20.projects=api2/project.xml,util20/project.xml,model20/project.xml,runtime20/project.xml,query20/project.xml,btree/project.xml,fostore20/project.xml,enhancer20/project.xml
 
 # release properties
 jdo.releases.dir = ${basedir.substring(0, basedir.lastIndexOf('jdo'))}jdo/releases



Mime
View raw message