What is your release process?
For me, it goes something like this.
First, I edit Changes and dist.ini. Some people automate filling their Changes entry from 'git log', I find this inappropriate since Changes are meant for users, not developers. I also still bump version number manually (though only in one place, dist.ini). Perhaps someday I'll automate it; my version numbering scheme is mostly a boring 0.01-increments anyway.
This modification to two files will be in the commit message that marks the release.
Then I "push the one-click release process button", by running a simple Perl script, without any arguments, in the dist's top-level directory. Thanks to Dist::Zilla, the script is fairly simple. It just needs to:
- Grab version number $ver from dist.ini.
- Run "dzil test".
- Determine if we're online, currently by attempting to DNS-resolve a known host like google.com.
- If we're online, run "dzil release". Otherwise, just "dzil build" and run another script to archive the release to some directory. BTW, dzil's release plugin also run this script, so releases are archived nonetheless.
- Run "git commit -am 'Release -v$ver' && git tag 'v$ver'"
The script bails if error is encountered in any of the steps.
Pushing to github (and/or gitorious, and/or bitbucket) is done using git's post-commit hook. The hook is also a Perl script. Aside from git-pushing, the script also notifies an internal forum and backups the repo whenever a backup media is mounted (I don't want to lose work due to a faulty hard drive, ever again).
I used a Twitter dzil plugin for a while, but stopped doing so mainly because the plugin used to broke every now and then. Now I think tweeting a release is not that useful anyway.
Starting from this week, I also run lint-prereqs before "dzil test", because so far the majority of my CT failure reports are about missing or circular dependencies. I do maintain dependencies manually because: 1) Some deps are dynamic and the in-stock tools cannot detect them anyway; 2) I want to be more aware and refrain from using needless dependencies as much as possible. 3) I want precise version requirements (instead of just requiring the newest version for everything).
Even though there is CPAN and BackPAN, I archive all my releases because: 1) sometimes I work offline and need offline access to the old releases; 2) my releases are usually tiny (less than 50-100KB); 3) using dzil means a lot of things get generated during release process instead of being put in the repo; 4) some releases are private, not targetted to CPAN.
The usual release process takes less than a minute, unless the Changes entry is quite long (e.g. more than a week's worth of work). The release script itself usually runs in 5-10 seconds or less (could be faster had dzil had decent startup speed :) ).
Some distributions, like this, is automated even more. Creating a new release is done entirely by a script. I aspire to do this for most of my distributions :)
Please share your own release process. Do you have a one-click release button? Do you archive your releases (and if so, where do you put the files)? How much time do you spend doing a typical release? How do you manage your dependencies? What other cool things you do during/after release?