After moving from CVS to SVN a number of years ago, I heavily modified my original first generation release script to take advantage of some of the basic features of SVN, like everything being accessible by HTTP by default.
For example, you can see the current incarnation of my release automation directly in the repository here:
http://svn.ali.as/cpan/tools/release.pl
Because my release automation is so intensely tuned to the way I work, I've never felt that (as a whole process) it was worth foisting on the CPAN. I find it quite interesting that of all the people with 100+ CPAN modules, no two of them use the same release system, and all of them (except maybe SMUELLER) rolled their own.
So I release bits and pieces, the reusable components used to implement single tasks, and that's been enough for me.
After 1000 releases, however, my current system is definitely feeling the strain. Although it makes releasing extremely quickly, the lack of awareness of the overall repository is becoming a problem.
With so many packages, and several dozen external committers, it has become impossible to know which modules in the trunk match the most recent release, which have updates, and whether or not those updates are significant.
It's also impossible to do any form of bulk updates, bulk incremental release, or bulk releases (something that has always bothered me when I maintain Module::Install).
So to mark the 1000th release by my second generation release automation, I've commenced development on a new third generation "release" automation system that could perhaps be more accurately described as a "repository automation system".
Having recommitted to using svn for my repository (for reasons that may become more obvious later) and with the code likely to be tied very closely to the way I work, it will most likely be of no direct use to anyone else. And the "release" packages won't be going up to the CPAN.
But if you interested in the whole release automation area, you may wish to watch and see what comes out of it.
You can see the beginnings of this work at the following path:
http://svn.ali.as/cpan/trunk/ADAMK-Repository/
The initial first few "releases" will be focused on building up a cohesive object model of my own repository. The intent is to understand what modules are maintained in the repository, what releases have been done and WHEN (in repository revision terms) and what SVN path/revision pairs map to which conceptual places.
With this in place, a second layer of logic can focus on issues of release state vs repository state, on change (and who made those changes), and on knowing if modules are passing tests, and whether or not arbitrary external patches will break those tests.
And finally, now I finally have a good Perl editor in sight (albeit 6 months or a year from being ideal for me), I have a chance to tie the repository automation directly to my editor with a personal plugin that lets me just look at any file within a package, and run a "release" command from a menu and have everything needed to SAFELY release modules.
And man, THAT would be awesome.
