Release Process

Starting a Release for DAS Subproject

This is work in progress. At this point, thoughts are put together to review with the community. Please help to complete this

Prerequisites

DAS releases are dependent on SDO release. Make sure we have a SDO release to base this release on.

Starting the release process

Identify a release manager on devlist.
The release manager initiates the discussion on the dev list or gathers previous dicussion threads related to the release content and starts a release thread discussion. Get consensus on the content frm the community early.
Nail the must-have functions from the community that is required to be delivered in this release.
Target (or reTarget) all of the Jira defects and new function that is required for the release. Move non-critical items to the next milestone.

During the release

Keep Jiras under control during the milestone. Make sure new opened ones are targeted for the appropriate release, and the backlog is decreasing.
Make sure the new function Jira are marked appropriately (since they will be used in the ReadMe file creation).
Look for Jira's that have patches attached to them and get the code integrated early in the cycle. Don't wait until the last minute.
Make sure that you begin to obtain clean versions for all SNAPSHOTs in the build. This can sometimes be a lengthy process as dependent packages are sometimes not available.
Lay out a plan for the distributed execution of the test suites (unit tests, integration tests, scenarios)
Ensure that all of the licenses are valid and replacements/remediation should be done.
Make sure that you remind the community that all modules should have the appropriate header file with the appropriate copyright statement.
Prepare for signing/authenticating distro files
1. identify/install s/w for public key infrastructure stuff and MD5 message digest generation
2. Create a PGP key for signing files
3. Lodge your PGP key with a keyserver
4. Put your public key in the svn KEYS file
Get set up for easy file transfer to people.apache.org
1. Identify/Install clients for ssh, secure copying and secure ftping
2. Establish authentication with people.apache.org by key
Ensure that there is inter-module understanding of how we plan to sequence releasing modules and requesting IPMC votes
ensure that our apache mentors know Tuscany's plans with respect to releases

Exiting the release cycle

Declare a candidate build to the community (RC) by uploading release candidate to release manager's web directory on people.apache.org. Work out any issues that are voiced.
Update the Readme file with the important New Function and a pointer to defect fixes for this release. Put the delivery date of the release at the top of the readme.
Get some to verify that all of the samples pass without issues. Integration tests and unit tests should run and known problems need to be identifed.
Initiate a vote on tuscany-dev mailing list for the release candidate to make the build a public release.
After 3 days, post the result to the devlist
Get approval from IPMC to make this a public release. Send a note to general@apache.org which summarizes the result of vote on devlist and include a pointer to the release in your note. 3 (+1) IPMC votes are required to make this a public release and of course no (-1).
Once you have IPMC support, post the release to people.apache.org.
update 'Download' link on the wiki and make it a goal to update or add documentation.
Don't forget that all this could not have been done without everyone's help. Post a congratulation note to the dev list and thank the entire team for their efforts to make this happen And thank you for the extra ordinary effort to make this happen