In the comments to a previous article, I mentioned that I use Module::Starter when starting a new distribution.

I actually use a custom profile along with the very handy Test::XT to produce robust release tests that won't break when people are just trying to install with the minimum fuss.

I thought it might be useful for other people if I wrote a quick tutorial on how to achieve the same results themselves.

I've failed the Perl Iron Man Challenge again, but I'm still alive, just busy.

I've had a couple of articles semi-written for the past two weeks, but they still very much works-in-progress, because they're about projects that are still... very much in-progress.

So I thought I'd post an interim report in the style of the "What I'm Working On" posts that crop up every so often.

One project is getting Pod::Weaver to do what I want, as mentioned in my previous article, "To Dist::Zilla, or not to Dist::Zilla?", this has involved using Moose for the first time, Pod::Weaver for the first time, Pod::Elemental for the first time, Config::MVP for the first time, and Git for the first time.

I maintain 38 Perl modules across 5 distributions on CPAN, which by the standards of some authors puts me firmly in the small fry category.

Nevertheless, the logistics behind each release does tend to drag after the 78th time. (Not that I'm counting.)

For example, bumping version numbers on each of the, 22 and rising, plugin modules for Template::Benchmark is just the sort of mindlessly repetitive thing that screams out to be automated, but I end up doing it manually each release.

Now this sounds exactly like a job for Dist::Zilla, so why haven't I switched?

Today I released a new beta of Template::Benchmark (v0.99_07) and one of the changes, along with the addition of 4 new template engine plugins (Tenjin, Template::Tiny, Text::Template::Simple and NTS::Template), is that it splits the author/release tests away from the install tests.

This was a royal PITA, so I thought I'd cover the how and why of what was done.