Author: psharples
Date: Wed Apr 25 14:57:56 2012
New Revision: 1330325
URL: http://svn.apache.org/viewvc?rev=1330325&view=rev
Log:
Updated release process documentation
Added:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-discuss.txt
(with props)
incubator/wookie/site/trunk/content/wookie/docs/developer/release-process.mdtext
(contents, props changed)
- copied, changed from r1306823,
incubator/wookie/site/trunk/content/wookie/docs/developer/release.mdtext
incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote-general.txt
(with props)
incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote.txt
(with props)
Added:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-discuss.txt
URL:
http://svn.apache.org/viewvc/incubator/wookie/site/trunk/content/wookie/docs/developer/release-discuss.txt?rev=1330325&view=auto
==============================================================================
---
incubator/wookie/site/trunk/content/wookie/docs/developer/release-discuss.txt
(added)
+++
incubator/wookie/site/trunk/content/wookie/docs/developer/release-discuss.txt
Wed Apr 25 14:57:56 2012
@@ -0,0 +1,15 @@
+To: [email protected]
+Subject: [DISCUSS] Apache Wookie *.*.* Release Candidate
+
+Discussion thread for vote on *.*.* release candidate.
+
+For more information on the release process, checkout -
+http://www.apache.org/dev/release.html
+
+Some of the things to check before voting are:
+- can you run the demo binaries
+- can you build the contents of source-release.zip and svn tag
+- do all of the staged jars/zips contain the required LICENSE, NOTICE and
+DISCLAIMER files
+- are all of the staged artifacts signed and the signature verifiable
+- is the signing key in the project's KEYS file and on a public server
Propchange:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-discuss.txt
------------------------------------------------------------------------------
svn:mime-type = text/plain
Copied:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-process.mdtext
(from r1306823,
incubator/wookie/site/trunk/content/wookie/docs/developer/release.mdtext)
URL:
http://svn.apache.org/viewvc/incubator/wookie/site/trunk/content/wookie/docs/developer/release-process.mdtext?p2=incubator/wookie/site/trunk/content/wookie/docs/developer/release-process.mdtext&p1=incubator/wookie/site/trunk/content/wookie/docs/developer/release.mdtext&r1=1306823&r2=1330325&rev=1330325&view=diff
==============================================================================
--- incubator/wookie/site/trunk/content/wookie/docs/developer/release.mdtext
(original)
+++
incubator/wookie/site/trunk/content/wookie/docs/developer/release-process.mdtext
Wed Apr 25 14:57:56 2012
@@ -1,4 +1,4 @@
-Title: Cutting a release
+Title: Release Process
Notice: 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
@@ -16,195 +16,341 @@ Notice: Licensed to the Apache Softwa
specific language governing permissions and limitations
under the License.
-# Introduction
+# Release Process
-This document is an overview of the release process for Apache Wookie
(Incubating).
+This document is an overview of the release process for Apache Wookie
(Incubating).
+Wookie uses a series of ant scripts coupled together with Apache Ivy to allow
automatic building of the code into its various release artifacts.
+It can also be used to automatically sign binaries and deploy artifacts to the
Nexus Repository.
+
+Make sure the [Release Setup](release-configuration.html) steps have been
performed.
+
+## What exactly do we build and release?
+
+You should familiarize yourself with the ant scripts in the project as they
are used to create the artifacts. We will go over the specific tasks for
generating them
+in more detail later.
+
+ Note the following 3 artifacts that are to be generated. Eventually these
should be made available to download from
[http://www.apache.org/dist/incubator/wookie/](http://www.apache.org/dist/incubator/wookie/)
+
+ 1. A source release (apache-wookie-VERSION-src.zip) (and also a tar.gz
version)
+ - this is for users who wish to download the code and build it
themselves
+ 2. A standalone release (apache-wookie-VERSION-standalone.zip) (and
also a tar.gz version)
+ - this is aimed at first time/casual users and incorparates a
preconfigured Jetty and Derby DB to work out of the box
+ 3. A WAR release (apache-wookie-VERSION-war.zip) (and also a tar.gz
version)
+ - this is aimed towards users who have an existing server setup
(their own tomcat/mysql system for example)
+ and want to deploy it alongside their own existing web
applications. The bundled documentation is geared towards
+ configuring it for tomcat/mysql but it also includes scripts
for other databases.
+
+ Additionally there are 3 Nexus artifacts to generate. Eventually these
should be made available from the Nexus Repository.
+
+ 4. A Nexus artifact of the wookie connector subproject
(wookie-java-connector-VERSION.jar)
+ - this is for users who want to incorporate the connector part
of wookie only as a jar via maven
+ 5. A Nexus artifact of the wookie parser subproject
(wookie-parser-VERSION.jar)
+ - this is for users who want to incorporate the w3c widget
parser part of wookie only as a jar via maven
+ 6. A Nexus artifact of the wookie WAR (wookie-VERSION.war)
+ - this is for users who want to include a self contained
version of the wookie.war in their own projects via maven.
+ (the difference between this and #3 is that this one is
configured & bundled with Derby DB.)
+
+## Steps to making a release
+
+### 1. Resolve Outstanding JIRA issues marked against this planned release
+ 1. Analyse open issues
+ 2. Issues should be FIXED and verified to ensure they are truly
fixed and thus marked as verified
+ 3. Alternatively, in some cases open issues can be moved to the
next planned release
+ 4. No open issues should remain against this intended release
before continuing
+ - The only exception to this is if an issue directly
addresses the build process, such as "create build for release" type issue.
+
+### 2. Communicate with committers regarding new release
+ Send an email to [email protected] and start a vote to
discuss whether everybody agrees it is okay to go ahead and make a release.
+ Ideally we'd want a +3 from the committers, but this is not always
possible.
+
+### 3. Check all Licenses, notices and other related files
+ 1. Check the following files found at the root of the trunk.
(They are bundled with all the builds, except in the case of LICENSE and
NOTICE, which are build specific)
+ 1. README - this is usually the first file a user will
read when they download either the source or binary versions of wookie.
+ This file usually will not need to be updated very
often, but as it points to other files and explains some of the different
builds, it should be checked for accuracy.
+ 2. RELEASE_NOTES - this must be updated with the list
of issues addressed since the last release.
+ This can be obtained from the wookie JIRA by selecting
all issues addressed for this planned version.
+ 3. UPGRADING - this must be updated if there were any
significant changes made to wookie since the last release.
+ Examples of this are - changes to the database which
means that users may have to manually migrate data using scripts
+ or where a major overhaul of the user interface OR API
means users would have to change/update their current practices for using those
parts of wookie
+ 4. NOTICE - this should be checked to make sure any new
components added to wookie since the last release are mentioned. Note: the
actual licences for these go into the LICENSE file.
+ 5. NEW_AND_NOTEWORTHY - this should be checked and
updated to point out and mention any new features in wookie since the last
release, that are deemed significant.
+ 6. BUILDING - this describes how to build wookie from
the source. This should be checked for accuracy, but will probably not change
very often.
+ 7. LICENSE - this file contains references to all the
licenses of the third party and contributed libaries and code used in wookie.
+ Any new libraries and code added since the last release
must have their licences added here. The main exception here is an existing
Apache Software Foundation library, which does not need to be included.
+
+ 2. Check the licences and notices found under
/trunk/etc/release/ (Note: some of the builds have specific LICENCE and NOTICE
files)
+ 1. /trunk/etc/release/maven/subprojects/LICENCE. This
licence file is bundled with all the maven artifacts
+ (except the maven WAR artifact) and should only contain
the apache license. (It is found in in the /META-INF folder of a generated .jar
file)
+ 2. /trunk/etc/release/maven/subprojects/NOTICE. This
notice file is bundled with all the maven artifacts
+ (except the maven WAR artifact) and should only contain
the apache license references. (It is found in in the /META-INF folder of a
generated .jar file)
+ 3. /trunk/etc/release/maven/war/LICENSE. This license
file is bundled with the maven WAR artifact only.
+ (It is found in in the /META-INF folder of a generated
.war file).
+ 4. /trunk/etc/release/maven/war/NOTICE. This notice
file is bundled with the maven WAR artifact only.
+ (It is found in in the /META-INF folder of a generated
.war file).
+ 5. /trunk/etc/release/standalone/LICENSE. This license
file is bundled with the standalone build only. (It is found at the root of the
generated standalone build)
+ 6. /trunk/etc/release/standalone/NOTICE. This notice
file is bundled with the standalone build only. (It is found at the root of the
generated standalone build)
+ 7.
/trunk/etc/release/standalone/STANDALONE_BUILD_NOTES. This should not change
very often, but a quick read through is recommended to make sure nothing has
changed.
+ (It is found at the root of the generated standalone
build)
+ 8. /trunk/etc/release/war/LICENSE. This license file is
bundled with the war build only. (It is found at the root of the generated war
build)
+ 9. /trunk/etc/release/war/NOTICE. This notice file is
bundled with the war build only. (It is found at the root of the generated war
build)
+ 10. /trunk/etc/release/war/WAR_BUILD_NOTES. This
should not change very often, but a quick read through is recommended to make
sure nothing has changed.
+ (It is found at the root of the generated war build)
+
+### 4. Check all files for license headers
+
+ Use the [Release Audit Tool
(RAT)](http://ci.apache.org/projects/wookie/rat-output.html) report to find any
missing license headers. Fix any missing entries.
+
+### 5. Update all references to SNAPSHOT in the properties files and update
the pom-templates
+
+ 1. Find the version reference '*.*.*-incubating-SNAPSHOT' in the
following files. Update it in each case removing the '-SNAPSHOT' at the end, so
that it reads '*.*.*-incubating'
+
+ /build.properties
+ /ivy.xml
+ /connector/java/build.properties
+ /connector/java/ivy.xml
+ /modules/jcr/build.properties
+ /modules/jcr/ivy.xml
+ /parser/java/build.properties
+ /parser/java/ivy.xml
+ /src/widgetserver.properties
+ /etc/release/runsignatures.bat
+
+ 2. Update the 3 pom-template.xml files so that the scm values reference
the tag version to be created
+
+ /pom-template.xml
+
+ Find...
+ <scm>
+
<connection>scm:svn:http://svn.apache.org/repos/asf/incubator/wookie/trunk</connection>
+
<developerConnection>scm:svn:https://svn.apache.org/repos/asf/incubator/wookie/trunk/</developerConnection>
+ <url>http://svn.apache.org/viewvc/incubator/wookie/trunk/</url>
+ </scm>
+
+ ...and update it (with correct version number) to read...
+
+ <scm>
+
<connection>scm:svn:http://svn.apache.org/repos/asf/incubator/wookie/tags/*.*.*-incubating</connection>
+
<developerConnection>scm:svn:https://svn.apache.org/repos/asf/incubator/wookie/tags/*.*.*-incubating/</developerConnection>
+
<url>http://svn.apache.org/viewvc/incubator/wookie/tags/*.*.*-incubating/</url>
+ </scm>
+
+ Do the same with the following two files...
+
+ /connector/java/pom-template.xml
+ /parser/java/pom-template.xml
+
+ 3. Commit your changes back to svn.
+
+### 6. Inform committers of temporary code freeze
+
+ Send an email to [email protected] informing that you are
about to tag the trunk.
+ (just in case there are commits while you are doing it. It only takes
a minute to tag it, so not a long freeze.)
+
+### 7. Create a tag of the current trunk state.
+
+ 1. Ensure you have checked out a clean copy of the trunk from
svn.
+ 2. In Eclipse select the wookie root folder and right click.
Choose team -> Tag...
+ 3. A dialog appears.
+ 4. In the Tag: box enter the release version number i.e.
'0.10.0-incubating'
+ - use the same version here as you entered in step
(5.2) when updating the pom-template files
+ 5. In the Comment box enter something sensible i.e. 'wookie
release 0.10.0-incubating'
+ 6. Click ok to create the tag.
+ 7. If you tick the "Start working in the tag" box, the tag will
be created and your local copy will update to the tagged version
+ 8. Verify the tag was created correctly & in the right place.
+ - In the Eclipse SVN Repository Exploring view you can
navigate to svn.apache.org/repos/asf/incubator/wookie/tags/ and make sure the
tag exists.
+
+### 8. Roll version number forward in all properties files in the trunk.
+
+ 1. If you haven't already, switch back to the trunk.
+ 2. Find all the files listed in step (#5.1) above.
+ 3. Update all the entries to the next version-SNAPSHOT - i.e.
0.11.0-incubating-SNAPSHOT
+ 4. Update the 3 pom-template.xml files in step (#5.2) above so
that they point back at the trunk again
+ 5. Commit your changes
+
+### 9. Inform commiters that you have finished
+
+ Send an email to [email protected] informing that you
have tagged the trunk for the build and that the trunk has now rolled to the
next version. (which also means the freeze has been lifted)
+
+### 10. Run the build script
+
+ 1. Switch back to the trunk. Run the ant task
'build-release-all' found in the root build.xml file
+ - either use eclipse to run it or use 'ant
build-release-all' on the command line at the wookie root folder
+ 2. This should generate a new folder at the root of wookie
called 'release' containing the following structure...
+
+ release
+ + *.*.*-incubating
+ + binary
+ + standalone
+
apache-wookie-*.*.*-incubating-standalone.tar.gz
+
apache-wookie-*.*.*-incubating-standalone.zip
+ rat-report.txt
+ + war
+
apache-wookie-*.*.*-incubating-war.tar.gz
+
apache-wookie-*.*.*-incubating-war.zip
+ rat-report.txt
+ + source
+
apache-wookie-*.*.*-incubating-src.tar.gz
+ apache-wookie-*.*.*-incubating-src.zip
+ rat-report.txt
+ runsignatures.bat
+
+ 3. The rat-report.txt files are for your reference and can be
removed when checked.
+ 4. Open a command prompt and run the 'runsignatures.bat' file
+ (AUTHOR NOTE: we need to either also supply a .sh version of
this or better still automate it)
+ - This creates the ASC signatures, MD5 and SHA files
needed for file verification
+ - This will only work if you have already followed the
steps outlined in the [Release Setup](release-configuration.html)
+ 5. Manually check the ASC, MD5 and SHA files are correct
+ - The generated ASC files are automatically checked
when you run the 'runsignatures.bat' (see how in the file), but the SHA and MD5
are not
+ - These can be checked using openssl at the command
prompt, for example...
+ - 'openssl sha512 <buildname.zip>' - should
generate same key on screen as found in the buildname.zip.sha file
+ - 'openssl md5 <buildname.zip>' - should
generate same key on screen as found in the buildname.zip.md5 file
+ 6. Open each build artifact and test that it...
+ - contains the correct NOTICE & LICENSE files
where appropriate
+ - the source builds will build from the command
prompt, using 'ant compile-core'
+ - the standalone builds will run when you click
it's startup script (May need to add executable permissions on mac/linux)
+ - examine the WAR build for integrity (also
ideally drop the WAR file into a preconfigured tomcat/mysql instance on your
machine to make sure it deploys/works okay)
+
+### 11. Upload the artifacts to people.apache.org
+
+ 1. Make sure you delete the 3 rat-report.txt files (otherwise the next
stage will upload them)
+ 2. From the 'wookie/release' folder run the following to upload the
generated build folder and artifacts...
+
+ scp -r ${project.version}
${user.name}@people.apache.org:/www/people.apache.org/builds/incubator/wookie/
+
+ ...substituting the ${project.version} with the folder name of the
generated artifacts i.e...
+
+ scp -r ./0.10.0-incubating
[email protected]:/www/people.apache.org/builds/incubator/wookie/
+
+ (Note: the pscp utility comes with putty, rather than scp)
+
+ 3. Verify they are downloadable from
http://people.apache.org/builds/incubator/wookie
+
+### 12. Upload the Nexus release artifacts
+
+ 1. If you use eclipse to run your ant tasks then right click the
/build.xml
+ - choose run as -> ant build...
+ - highlight the "Main" tab and in the "Arguments" panel add the
following
+
+ -Duser.name="My Name" -Dupload.user=your_apache_userid
+ -Dupload.password=your_svn_password
-Dpgp.password=your_pgp_password -Dpgp.keyId=your_pgp_keyid
+
+ (substituting your details where applicable)
+
+ - click apply.
+ 2. To check/preview the Nexus artifacts locally first run 'ant
publish-local' found in the root build.xml file
+ - this publishes all artifacts (parser, connector and self
contained WAR) locally only and
+ can be found under
${user.home}\.m2\repository\org\apache\wookie
+ 3. Once again check to make sure the correct LICENSE and NOTICE files
appear in each /META-INF folder found within each archive
+ 4. When you are happy the generated files are okay, either run the
following ant task at the command prompt to deploy to Nexus...
+
+ ant publish-maven-release-artifacts
publish-subproject-artifacts-to-release-repo -Duser.name="My Name"
-Dupload.user=your_apache_userid
+ -Dupload.user=your_apache_userid
-Dupload.password=your_svn_password -Dpgp.password=your_pgp_password
-Dpgp.keyId=your_pgp_keyid
+
+ or if you have completed step (1.) above, simply right click the root
build.xml and choose to run 'publish-maven-release-artifacts'
+ and 'publish-subproject-artifacts-to-release-repo'
+ (AUTHOR NOTE: we need to merge these ant tasks into 1 call)
+
+ 5. Verify the staged artifacts in the Nexus repository
+ https://repository.apache.org/index.html
+ Staging repositories (under Build Promotion) --> Name column
--> org.apache.wookie
+ Navigate through the artifact tree and make sure that all
javadoc, sources, tests, jars, ... have .asc (GPG signature) and .md5 files.
+ See http://people.apache.org/~henkp/repo/faq.html and
http://www.apache.org/dev/release-signing.html#openpgp-ascii-detach-sig
+
+ 6. Close the Nexus staging repository
+ https://repository.apache.org/index.html
+ Staging repositories (under Build Promotion) --> Name column
--> org.apache.wookie
+ Click checkbox for the open staging repo
(org.apache.wookie-XXX) and press Close in the menu bar.
+
+### 13. Put the release candidate up for a vote on the wookie-dev list
+
+ 1. Create a VOTE email thread on wookie-dev@ to record votes as
replies, like [this](release-vote.txt)
+ 2. Create a DISCUSS email thread on wookie-dev@ for any vote questions,
[this](release-discuss.txt)
+ 3. Perform a review of the release and cast your vote. See the
following for more details on Apache releases
+
+
[http://www.apache.org/dev/release.html](http://www.apache.org/dev/release.html)
+
+ 4. A -1 vote does not necessarily mean that the vote must be redone,
however it is usually a good idea to rollback the release if a -1 vote is
received.
+ - See - Recovering from a vetoed release
+
+ 5. After the vote has been open for at least 72 hours, has at least
three +1 PMC votes and no -1 votes, then post the results to the vote thread
+ - reply to the initial email and prepend to the original
subject "[RESULT]"
+ - Include a list of everyone who voted +1, 0 or -1.
+
+### 14. Put the release candidate up for a vote on the incubator general list
+
+ 1. Create similar VOTE email on the [email protected] list,
like [this](release-vote-general.txt)
+ - Depending on how many binding +1 IPMC votes the release
candidates received, you may need to wait for additional ones from the general
list
+ 2. After the vote has been open for at least 72 hours and has at least
three +1 IPMC votes (in total) then post the results to the vote thread
+ - reply to the initial email and prepend to the original
subject "[RESULT]"
+ - Include a list of everyone who voted +1, 0 or -1.
+ 3. NOTE: For the release candidate to be successful it must at least
have received at least 3 +1 IPMC votes combined from both wookie-dev and
general.
+
+### 15. Finalizing a release
+
+ 1. Promote the staged nexus artifacts
+ - https://repository.apache.org/index.html
+ - Staging repositories (under Build Promotion) --> Name column
--> org.apache.wookie
+ - Click checkbox of the closed staging repo
(org.apache.wookie-***) and select Release.
+ 2. Copy the release artifacts over to the distribution area
+ - login to people.apache.org and copy across the build folder
+
+ cp -r
/www/people.apache.org/builds/incubator/wookie/*.*.*-incubating
/www/www.apache.org/dist/incubator/wookie
+
+ (replacing the version name accordingly)
+
+ - verify the folder and contents copied across okay.
+ 3. Delete the staged version (cleanup)
+ - login to people.apache.org (if not already) and delete the
old staged release
+
+ rm -rfv
/www/people.apache.org/builds/incubator/wookie/*.*.*-incubating
+
+ (replacing the version name accordingly)
+
+ 4. Update the staged website
+ - Update the downloads page to add new version using the
mirrored URLs
+ - Modify the URL for the prior release to the archived URL for
the release
+
+ 5. Publish the website
+ - Wait 24hrs after committing releases for mirrors to replicate
+ - Publish updates to the download page
+
+### 16. Update JIRA
+
+ 1. Update the JIRA versions page to close all issues, mark the version
as "released", and set the date to the date that the release was approved.
+ You may also need to make a new release entry for the next release.
+
+### 17. Announcing the release
+
+ 1. Make a news announcement on the Wookie News page.
+ 2. Make an announcement about the release on the following lists
+ - [email protected]
+ - [email protected]
+ - [email protected]
+
+### 18. Recovering from a vetoed release
+
+ 1. Reply to the initial vote email and prepend to the original subject -
+
+ [CANCELED]
+
+ 2. Delete the svn tag you created in step (7) above. Either use eclipse to
do this or via command prompt
+
+ $ svn del
https://svn.apache.org/repos/asf/incubator/wookie/tags/${project.version} -m
"deleting tag from rolled back release"
+
+ 3. Delete the build artifacts on people
+
+ $ rm -rfv
/www/people.apache.org/builds/incubator/wookie/${project.version}
+
+ 4. Drop the nexus staging repo
+ https://repository.apache.org/index.html
+ Enterprise --> Staging
+ Staging tab --> Name column --> org.apache.wookie
+ Right click on the closed staging repo (org.apache.wookie-XXX) and
select Drop.
-# Release Phases
+ 5. Make the required updates that caused the vote to be canceled during
the next release cycle
-This section summarises each phase in the release process. There are more
details for each phase in the sections below.
- 1. Development
- 1. Analyze Open Issues
- 1. Issue Fixing - ongoing - all issues should be resolved or moved
- 1. Issue Validation - all resolved issues must be checked as being truly
fixed and thus marker as verified
- 1. Collect committer public keys
- 1. Licence Audit and Legal Audit - including headers, dependencies,
LICENCE and NOTICE files
- 1. Release Candidate
- 1. Licence Audit and Legal Audit - including headers, dependencies,
LICENCE and NOTICE files
- 1. Documentation â Check installation and build documentation for
accuracy, create status document, create release notes
- 1. Create release branch on SVN â sign binaries, permissions
- 1. Test, test, test! (repeat from previous step until no problems emerge
in test)
- 1. Prepare for release
- 1. Write the release announcement (with approval from press@)
- 1. Tag the release branch
- 1. Build the release files
- 1. Signing of release files
- 1. Vote on release
- 1. Request approval from Incubator PCM
- 1. Release
- 1. Upload to incubator distributions site
- 1. Wait for mirroring to take place
- 1. Announce the release
-## Development
-These steps are to be carried out in the run up to a relase. They are, in the
main, an ongoing activity
-rather than a part of the release cycle itself.
-### Open Issues
-
-A list of outstanding issues is generated from Jira. This list is posted to
the project developer list
-with suggestions to either implement for the release or postpone for the next
release. After community
-discussion JIRA is updated accordingly.
-
-When deciding whether to implement an issue for this release be aware of
taking on too much. It is more
-important to get a release out than to complete all features. Release early,
release often.
-
-Once complete this process gives a clear definition of what will be included
in the release and allows
-timescales to be estimated.
-
-### Issue Fixing and Verification
-
-Each issue for the release to be fixed then the fixes to be tested, reviewed
and accepted.
-
-### Signatures
-
-The committers for the project need to provide public keys for the release,
each person who submits a
-key needs to keep the private key safe. These will be included with the
release in a KEYS file. The
-process of creating a key pair should be consistent across the committers.
Apache recommend using
-GNU Privacy Guard to generate keys and sign the artifacts.
-
-Committers without a code signing key should generate one - RSA 4096 bits
-
-If committers have a DSA or RSA key of less than 2048 bits then a new one
should be generated for
-signing releases, again using RSA 4096 bit.
-
-For committers who already have an RSA key of 2048 bits or more some
configuration of their client
-to avoid weaknesses are required. Instructions on how to do this can be found
-[here](http://www.apache.org/dev/openpgp.html#sha1).
-
-#### Web of Trust
-
-Once individuals have generated keys, opportunities should be taken (where
possible)
-to join the Apache Web of Trust. First the keys should be uploaded to a public
key
-server (is there a recommended one we should use?). Next key signing: if
conferences
-are attended or events where there are other Apache developers and there are
key
-signing parties.
-
-### License Audit and Legal Audit
-
-There is a need to check all licenses manually, including headers in source
files etc...
-The licenses for all libraries should be in place. LICENSE and NOTICE files
need to
-be created. The Release Audit Tool (RAT)
[report](http://ci.apache.org/projects/wookie/rat-output.html)
-is helpful in this regard.
-
-In licenses/all_licenses.txt record the details of all dependencies; this
should include not
-only any libraries referenced directly in ivy.xml, but also any dependencies
of features, connectors
-and widgets. It is not, however, necessary to document licenses of secondary
dependencies.
-
-The LICENSE file should contain our license and the licenses for all
dependencies underneath.
-The NOTICE file contains the following text modified for our project and the
notices from
-dependencies underneath.
-
-Apache PRODUCT_NAME
-Copyright yyyy The Apache Software Foundation
-
-
-This product includes software developed at
-The Apache Software Foundation (http://www.apache.org/).
-
-## Release Candidate
-
-This is the first real phase of the release process.
-
-### Documentation
-
-The installation and build documentation which is included with the release
needs to be
-checked for accuracy. Other documentation is maintained online and can be
modified when
-required. When we announce the release it would be good to review the
documentation for
-accuracy and usability. The status document can be generated from the issue
tracker with
-some introduction. Release notes need to be created including the standard
incubator disclaimer.
-
-### Release Branch
-
-When we reach code freeze a branch should be created in which the release is
built and
-signed. This will allow continued development on trunk. The branch can also
be used to
-maintain the release, but any changes or fixes there need to be merged back
into trunk.
-There is a detailed description here of an approach similar to this. When
built and
-signed the branch should be considered the release candidate for testing.
-
-### Build the release candidate
-
-The release candidate files are built from the release branch. The files to be
provided are:
-
- * source distribution
- * standalone distribution
- * WAR distribution
-
-### Testing
-
-The final build should be tested on all supported platforms, we provide a
[minimal testing
-script](releaseTesting.html) for your to follow.
-
-If any tests identify problems the community needs to decide if this is a
blocker to the release or not.
-If not a blocker the issue should be documented, if a blocker it should be
fixed and a new
-release candidate is built.
-
-## Prepare for release
-
-This is where we build the actual release.
-
-### Write release announcement
-
-The release announcement is written in cooperation with the press@ list.
-
-### Tag the release branch
-
-The release branch is tagged with the release number.
-
-### Build release files
-
-All release files are built from the tagged branch. Release files are:
-
- * source distribution
- * standalone distribution
- * WAR distribution
-
-### Signing of release files
-
-A minimum of three committers must sign the release using their keys avilable
in SVN.
-
-## Vote on the release
-
-The community votes on the release. Since the release candidate has been
thoroughly tested
-by the community this should be a formality. However, it is an important
formality as it
-indicates that the project management committee have verified the legal
integrity of the
-release.
-
-If you are a PMC member you should not vote +1 unless you are satisfied that
the software is,
-to the best of your knowledge, ready for release.
-
-## Request incubator approval
-
-Whilst in the incubator the project needs to have official approvel from the
Incubator PMC.
-As with the community vote this should be a formality, however, many incubator
PMC
-members will check the legal status of the release as an added precaution.
-
-## Release
-
-All there is to do now is get the release out there.
-
-### Upload to incubator distribution site
-
-Once you have uploaded the files to the incubator distribution site you will
need to check
-permissions and wait for mirroring to take place.
-
-### Announce the release
-
-The release announcement needs to be posted to:
-
- * announce@
- * wookie-users@
- * wookie-dev@
- * project website
\ No newline at end of file
+
\ No newline at end of file
Propchange:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-process.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote-general.txt
URL:
http://svn.apache.org/viewvc/incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote-general.txt?rev=1330325&view=auto
==============================================================================
---
incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote-general.txt
(added)
+++
incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote-general.txt
Wed Apr 25 14:57:56 2012
@@ -0,0 +1,34 @@
+To: [email protected]
+cc: [email protected]
+Subject: [VOTE] Release Apache Wookie *.*.*-incubating (General Incubation
List)
+
+This is the (*iteration) incubator release for Apache Wookie, with the
artifacts being versioned as *.*.*-incubating.
+
+We have already received * IPMC +1 votes (plus an additional * PPMC +1 votes)
during the release voting on wookie-dev. (We need * more IPMC vote)
+
+Vote thread:
+http://incubator.markmail.org/search/xxxxxxxxxxxxxxxxxxxxxxxxxxx
+
+Result:
+http://incubator.markmail.org/search/xxxxxxxxxxxxxxxxxxxxxxxxxxx
+
+Svn source tag:
+https://svn.apache.org/repos/asf/incubator/wookie/tags/*.*.*-incubating/
+
+Release notes:
+https://svn.apache.org/repos/asf/incubator/wookie/tags/*.*.*-incubating/RELEASE_NOTES
+
+Release artifacts:
+http://people.apache.org/builds/incubator/wookie/staging-area/*.*.*-incubating
+
+Maven artifacts
+https://repository.apache.org/content/repositories/orgapachewookie-***/
+
+PGP release keys:
+https://svn.apache.org/repos/asf/incubator/wookie/KEYS
+
+Vote open for 72 hours.
+
+[ ] +1 approve
+[ ] +0 no opinion
+[ ] -1 disapprove (and reason why)
\ No newline at end of file
Propchange:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote-general.txt
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote.txt
URL:
http://svn.apache.org/viewvc/incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote.txt?rev=1330325&view=auto
==============================================================================
--- incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote.txt
(added)
+++ incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote.txt
Wed Apr 25 14:57:56 2012
@@ -0,0 +1,33 @@
+To: [email protected]
+Subject: [VOTE] Apache Wookie ${version} Release Candidate
+
+This is the *iteration incubator release for Apache Wookie, with the artifacts
being versioned as *.*.*-incubating.
+
+We are requesting a vote via wookie-dev for the release of the artifacts in
the first instance found here...
+
+http://people.apache.org/builds/incubator/wookie/*.*.*-incubating/
+
+...as the final *.*.*-incubating release.
+
+PGP release keys (signed using DDED352A):
+
+http://www.apache.org/dist/incubator/wookie/KEYS
+
+Additionally there are 3 sets of maven artifacts, which we hope will help
+others to integrate WOOKIE into their own applications. These are...
+
+1. Wookie itself as a downloadable WAR
+2. The W3C parser
+3. The Java connector framework
+
+These artifacts are now in the staging area found here...
+
+https://repository.apache.org/content/repositories/orgapachewookie-***/
+
+Please take the time to verify the artifacts before casting your vote.
+
+Vote will be open at least 72 hours but until we receive most of the
committers votes.
+
+[ ] +1 approve
+[ ] +0 no opinion
+[ ] -1 disapprove (and reason why)
\ No newline at end of file
Propchange:
incubator/wookie/site/trunk/content/wookie/docs/developer/release-vote.txt
------------------------------------------------------------------------------
svn:mime-type = text/plain
