Release process

1. Update CONTRIBUTORS

   • generate from git log => .mailmap?
   • sort the results alphabetically

2. Update ChangeLog

   • generate from git log with misc/changelogger 'Release Manager' '<[email protected]> 1.2.3_04
   • review the results and clean up any noise coming from commit messages
   • IDEA: maintain a changelog manually, and then let Dist::Zilla figure out the new version number according to semantic versioning rules based on the change categories

3. Edit dist.ini

   • bump version number according to semantic versioning rules
     • add _0x suffix for dev releases (like: 1.7.0 -> 1.7.0_01 = 1.7.1-rc1 -> 1.7.1)
   • change release_status to testing for dev releases
   • commit the dist.ini version/status changes as Release 1.7.0_01 aka 1.7.1-rc1 to a branch named release-1.7.0_01

4. Open a PR about the release

5. Wait for CI/human feedback

6. While waiting, it is a good time to go and prepare the release notes for the website

   • base it on the changelog, following previous release notes as template
   • push it to the website repo, open a PR, and wait for CI/human feedback with the release note too

7. When all is well, merge the PR to master and tag the release commit with the version (git tag 1.7.0_01)

8. Make sure to push the merge result and the tag to GitHub

9. Publish the release notes to the website

10. Announce new release on the various channels

    • mailing list
    • IRC
    • twitter