You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Starting a Release for DAS Subproject

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

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 frm the community early.
  3. 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

  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. Declare a candidate build to the community (RC).
  8. Make sure that you remind the community that all modules should have the appropriate header file with the appropriate copyright statement.

Exiting the release cycle

  1. Upload release candidate to release manager's web directory on people.apache.org. Declare a candidate build to the community and work any issues that are voiced.
  2. 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.
  3. 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.
  4. Initiate a vote on tuscany-dev mailing list for the release candidate to make the build a public release.
  5. After 3 days, post the result to the devlist
  6. Now, you need to go to IPMC for approval to post this as a public release. Send a note to general@apache.org which summarizes the result of vote on devlist and points to the release candidate. 3 (+1) IPMC votes are required to make this a public release and of course no (-1).
  7. Once you have IPMC support, post the release to people.apache.org.
  8. update download page of the wiki and make it a goal to update or add documentation.
  9. 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 (smile)

Good References in case of question

  • No labels