Release & Branch Process

Each time we release a new version of mail, we follow this release process to ensure that developers can track the changes in the change log and we can support branches into the future.

The process runs like this for releasing the next version of the gem, in this example we will release 2.8.0 gem.

1. Create a new branch (2-8-stable) off of the current master indended to be the next gem release
2. Modify Mail::Version to 2.8.0.rc1
3. Commit 2 to the 2-8-stable branch with the comment Stable branch for 2.8.x releases and tag it 2.8.0.rc1
4. Build the 2.8.0.rc1 gem and push to rubygems.org
5. Switch back to the master branch
6. Clear out the entries under each subheading in the CHANGELOG and change the version to 2.9.0 (unreleased)
7. Modify Mail::Version to 2.9.0-edge
8. Commit 7 and 8 to the master branch with comment Now tracking 2.9.0.edge. See 2-8-stable for 2.8.x releases.
9. CONDITIONAL: If breaking changes are found in the gem build, fix these directly on the 2-8-stable branch and master branches as appropriate, and update the changelog and release a rc2 release.
10. After approximately a week, (no less than 5 days) with no other changes needing to be committed to stable, switch to the 2-8-stable branch.
11. Update the CHANGELOG.rdoc file to add the date and replace 2.8.0 (unreleased) with 2.8.0 (DD-Mmm-YYYY) and add == Version 2.8.1 (unreleased) to the top.
12. Update the Mail::Version to 2.8.0.nil
13. Commit 11 and 12 to the 2-8-stable branch with the comment 2.8.0 Release and tag it 2.8.0
14. Build the 2.8.0 gem and push to rubygems.org