Release process

1. 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

2. 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

3. Open a PR about the release

4. Wait for CI/human feedback

5. 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

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

7. Build Rex with dzil build

8. Check the build contents as needed

9. Upload tarball to PAUSE

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

11. Publish the release notes to the website

12. Announce new release on the various channels

    • mailing list
    • IRC
    • twitter