Release Planning Suggestions

  1. Set release date
  2. Define type of release and release number; i.e. major, minor, patch; 1.2.1, 1.3, etc.
  3. Verify consistent understanding of Spec
    • Clarify Spec as needed
    • Determine which products are OK to be out of compliance
  4. Freeze/document Spec understanding
    • do NOT change until after release
    • if changes needed after freeze; re-assess release date
  5. Define the set of capabilities/functionality to be included
    • Start with minimal set
    • included other options based on time available
  6. Set code freeze date for repository trunk
  7. Branch repository
    • Do NOT work on trunk until branch is completed
  8. Run test suite on branch – daily depending on number of failures
  9. Focus all code work on branch; with merges back to trunk as needed
    • Merges back to trunk should be performed asap after developer changes release candidate branch. Even if changes on RC are not intended for trunk, the merge (and then revert) needs to be done to prevent other developers from stumbling into it.
  10. When all tests pass, or failures are understood and deemed to be acceptable, code is ready for release