svn commit: r411941 - /db/jdo/HowToReleaseJDO.txt

[cl...@apache.org]

Author: clr
Date: Mon Jun  5 15:54:42 2006
New Revision: 411941

URL: http://svn.apache.org/viewvc?rev=411941&view=rev
Log:
JDO-365 create instructions for releasing JDO

Added:
    db/jdo/HowToReleaseJDO.txt

Added: db/jdo/HowToReleaseJDO.txt
URL: http://svn.apache.org/viewvc/db/jdo/HowToReleaseJDO.txt?rev=411941&view=auto
==============================================================================
--- db/jdo/HowToReleaseJDO.txt (added)
+++ db/jdo/HowToReleaseJDO.txt Mon Jun  5 15:54:42 2006
@@ -0,0 +1,157 @@
+How to Release an Apache JDO Distribution
+
+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.
+
+The process is performed by a release manager with cooperation from testers
+in the community.
+
+Overview of the process:
+
+The community first decides on the name of the release. The format
+of the name is <spec-number>.<major>.<minor>.<update>. The spec-number
+is either 1 for JDO 1 or 2 for JDO 2. The major number might change for
+a new JSR. The minor number would change for a specification revision
+approved by the JCP via specification maintenance review. The update number
+can be used for changes that do not need a maintenance review and
+do not change the interfaces.   Trailing <update> and <minor> numbers
+with zero values are right trimmed, so there might be a 2.0.0.1 or a 2.0.1
+but not a 2.0.0 or 2.0.1.0.
+
+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.
+
+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.
+
+The release manager modifies the branch to change dependencies from SNAPSHOT
+to projects in the release.
+
+The release manager builds and tests the components of the release and
+checks the release build into svn.
+
+The release manager publishes the release on a staging area of the apache
+server and calls for the community to test the release.
+
+The community tests the release. If necessary, cycle until all issues are
+resolved.
+
+The release manager calls for a vote to release by sending a message to the
+community and forwarding the message to the pmc.
+
+The community votes on the release. If necessary, cycle until issues are 
+resolved.
+
+The release manager notifies the pmc of the successful vote outcome.
+Note that a successful vote includes three +1 votes from PMC members.
+
+The release manager distributes the release, which is then copied to mirror
+sites worldwide.
+
+The release manager notifies the worldwide community of the availability
+of the release.
+
+Detailed process steps:
+
+1. Create a branch from the trunk or from another branch. If you are 
+creating a major release, e.g. 2.0, create a 2.0 branch from the
+trunk. If creating an update release, e.g. 2.0.1.3, create a branch from
+the 2.0.1 or 2.0.1.2 branch and apply updates to it.
+
+cd jdo
+svn copy https://svn.apache.org/repos/asf/db/jdo/trunk \
+https://svn.apache.org/repos/asf/db/jdo/branches/2.0
+
+2. Remove the projects and files that are not being released.
+
+pushd branches/2.0
+svn rm api11 btree fostore20 query20 runtime20 ri11 tck11 JDO11.MF 
+svn commit -m "Remove projects and files that are not being released"
+
+3. Update dependencies in projects to be released.
+
+For each project.xml in the branch:
+sed /SNAPSHOT/2.0/gcd 
+popd
+
+If needed, update the dependency to JPOX in the tck20 project.xml.
+If needed, apply patches from the trunk or branches to the new branch.
+
+4. 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.
+
+cp trunk/lib/ext/* branches/2.0/lib/ext
+
+5. 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.0/dist directory. The dist directory is in a format that
+can be copied directly to the apache dist directory for distribution.
+
+pushd branches/2.0
+maven tck20.dist
+popd
+
+6. Test the release in the branch.
+
+pushd branches/2.0/tck20
+maven installSchema
+maven runtck.jdori
+popd
+
+7. 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).
+
+bin/sign-directory releases/2.0/dist
+
+8. Push the artifacts to the staging area on the apache server.
+
+scp -r releases/2.0/dist people.apache.org:~/public_html
+
+9. Test the release from the staging area. 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 pmc@db.apache.org. Iterate until you get a successful vote. Mail the 
+results of the vote to jdo-dev@db.apache.org, bcc: pmc@db.apache.org, and 
+include [VOTE] [RESULTS] in the subject line.
+
+10. 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.
+
+ssh people.apache.org
+cp -r public_html/dist /www/www.apache.org
+
+11. Check the distribution into svn
+
+svn add releases/2.0
+svn commit "JDO-XXX create release 2.0" releases/2.0
+
+12. Update the JDO web site to point the downloads page to the release.
+In site/xdocs/releases create release-2.0.html.  In site/docs/releases create
+release-2.0.cgi.  The .cgi file contents are identical to the other .cgi
+files in the release directory; only the file name differs.  Edit 
+site/xdocs/downloads.xml to link to the new release page .cgi document.
+Set the svn properties svn:eol-style to native and svn:executable to true 
+for the .cgi files. Build the site from the site directory:
+
+ant
+svn add xdocs/releases/release-2.0.html 
+svn add docs/releases/release-2.0.html 
+svn add docs/releases/release-2.0.cgi 
+svn commit
+
+Follow the instructions in HOWTO to push the site changes to
+the Apache web site.
+
+13. Announce the release to the Apache community via email to 
+announce@general.apache.org
+
+14. This step is only to avoid instructions with 13 steps.