2016/05/28 - Apache Tuscany has been retired.

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

What's a Release

The ASF release definition basically says that any artifact that is made available for people outside of the Apache Tuscany project is considered a release. The Release process usually consist of preparing the contents of the release on the project dev-list, voting release candidate(s) and, because Tuscany is still under Incubation, asking the iPMC to approve the release after it has already been approved on the project development community.

Prerequisites

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

Starting the release process

1. Identify a release manager on devlist.
2. 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 from the community early.
3. Nail the must-have functions from the community that is required to be delivered in this release.
4. 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

1. Keep Jiras under control during the milestone. Make sure new opened ones are targeted for the appropriate release, and the backlog is decreasing.
2. Make sure the new function Jira are marked appropriately (since they will be used in the ReadMe file creation).
3. 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.
4. 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.
5. Lay out a plan for the distributed execution of the test suites (unit tests, integration tests, scenarios)
6. Ensure that all of the licenses are valid and replacements/remediation should be done.
7. Make sure that you remind the community that all modules should have the appropriate header file with the appropriate copyright statement.
8. 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
9. 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
10. Ensure that there is inter-module understanding of how we plan to sequence releasing modules and requesting IPMC votes
11. make the trunk reference the newly released parent pom and buildtools
12. optionally make a branch
13. stabilize code in branch (or trunk if development activity can be halted in trunk)
    1. check LICENSE and NOTICE files in project roots and in jar manifests
       1. run the rat tool against the source and check for exceptions
       2. once exceptions have been fixed, store the rat log and make a note of rat log exceptions which are there because they have to be
       3. repeat this as necessary during the release process if new files are included
    2. update readme 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.

1. 1. Ensure the DAS Tuscany project's root level svn Status file is up to date, and then copy/update it into the root folders of any source distribution that will be made,

Exiting the release cycle

1. Create a release candidate
   1. Create local copies of source hierarchies, , one per source distribution, using svn export <uri> <local-dir>
   2. Make archives of your clean exports in order to be able to distribute source
   3. Follow the instructions in BUILDING.txt in the root folders of the source distributions to produce the binary distribution
   4. Test binary distro on a clean machine before publishing it as an RC.
   5. When ready, put in place distro signing capabilities
      1. Sign and create md5 checksums for each of the source and binary distribution archives
      2. transfer the archives to a logical place under your public_html people.apache.org space
      3. create a suitable readme for the root level of your release candidate folder, and ensure the readme names the release candidate version

1. Declare a candidate build and ask for feedback on devlist and user list. Work out any issues that are voiced.
2. 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.
3. Initiate a vote on tuscany-dev mailing list for the release candidate to make the build a public release.
4. After 3 days, post the result to the devlist
5. Once the community approved the candidate, create a tag from the branch (or trunk if no branch)
   1. Note that a release must have a referenceable tag
      svn will complain when you try to do an svn commit into a tag, which is a warning only, and during this phase of the release process, updates to a tag are justifiable
6. 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).
7. Once you have IPMC approval, post the release to people.apache.org.
8. Update the version elements of the poms to define the version of the parent pom and buildtools that should be used
9. Update the tags version names of the distributable artifacts to non SNAPSHOT titles that match the release name
10. Update the tags version names of the dependencies to non SNAPSHOT versions, if not already done earlier in the release candidate process
11. Ideally update the tags version names of maven plugins to non SNAPSHOT versions if not already done earlier in the release candidate process (note that if the plugin behaviour changes after release, your tag or source distribution may not build in the same way as it did when you released if you rely on SNAPSHOT plugin versions)
12. Rebuild and upload a new release to /www/people.apache.org/dist/incubator/tuscany/java
13. update 'Download' link on the wiki and make it a goal to update or add documentation.
14. Announce the release by sending to anounce@apache.org (note that you must use an apache.org email address to do this), copying tuscany-dev, tuscany-user and general@incubator
15. 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

Good References

• Apache Release: http://www.apache.org/dev/release.html
• Apache Release Management: http://incubator.apache.org/guides/releasemanagement.html
• Apache release publishing guide: http://www.apache.org/dev/release-publishing.html
• ARAT: http://code.google.com/p/arat/
• Apache Voting: http://www.apache.org/foundation/voting.html
• Signing Releases: http://www.apache.org/dev/release-signing.html

Examples

http://wiki.apache.org/ws/FrontPage/Axis2C/releases/steps

• Release process from Apache Cayenne: http://cwiki.apache.org/CAY/release-guide.html
• Release process from Apache Geronimo: http://cwiki.apache.org/GMOxPMGT/release-manager-checklist.html