There is plenty. Like module-names being hardcoded into tests.

FWIW: There are other modules which try to solve this issue.

like Module::Starter::AddModule

I think I will fall back to a more dynamic approach, using pseudo.t files in my test directory automating the updates whenever I run prove.

Things like updating .pod files and README by templates and updating the VERSION number. And updating the manifest and so on.

I think all those maintenance tasks are outside of what Module::Starter purports to do.

Just as an example, here's how I do these things:

• Test files don't need to know the module names besides their functionality, so changing the module name/splitting a module name will obviously also need editing the test. But most likely this also comes with a change in the API, so something more needs to change anyway.
• If a test file really needs to know about the name of the (main) module, I have that test load my Makefile.PL, which can provide that information through a function.
• I don't know why updating POD files would be a problem, but then I only use POD files for documentation that has no additional code. All other documentation lives in the .pm file itself and gets updated by me writing that.
• Updating the version number of a distribution is a job for perl-reversion in Perl::Version.
• Updating the MANIFEST file is done by make manifest.
• Updating the META.* files is done by make distmeta.

There are other approaches, for example I don't know how Module::Build-based distributions manage these files.

There are Dist::Zilla and Dist::Minilla, which also allow you to manage a distribution, but I dislike them as for supplying a patch or running the test suite on a Git checkout of such a module, you also need to install the same distribution builder and all the plugins that the author has used for this distribution.

Corion:

There are Dist::Zilla and Dist::Minilla, which also allow you to manage a distribution, but I dislike them as for supplying a patch or running the test suite on a Git checkout of such a module, you also need to install the same distribution builder and all the plugins that the author has used for this distribution.

Installing the plugins can be avoided if the Makefile.PL (or Build.PL) created by the tools is included in the Git repository, and I seem to recall that this practice has been recommended in dzil circles. Also, it should be possible to run the tests with prove. While participating in the CPAN Pull Request Challenge I've seen modules with insane plugin lists which I did not want to install, but prove was fully sufficient.

I myself was reluctant to use Dist::* for a long time, but mostly because of the guesswork needed to figure out which plugin does what, how they can be configured and how they interact with each other. The documentation is often extremely short. Eventually I found that the benefits of skeletons and different profiles (e.g. for Moose / non-Moose boilerplate) outweigh the learning curve and am now using Dist::Zilla - with a minimal list of plugins.

The POD normally mirrors the version number, does Perl::Version help to update this too?

And I prefer to have the usage information and licence inside separate Module.pod file.

The POD inside the the .pm will be used to generate the .pod, but will also contain information relevant for the maintainer . Like having a =head1 for Exported or Methods which will be shown in the Module.pod, while documentation for =head1 Internal subs are hidden.

Much saner, I don't need repeated informations and boilerplate when looking into code. And refactoring becomes easier.

> Test files don't need to know the module names

I'm not sure how you unit test a sub-module without use -ing it.°

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}

update

Furthermore there is plenty of code in POD which should be tested too. Like from Synopsis, Examples and Tutorials.

°) you mean prove -M ?

> Test files don't need to know the module names besides their functionality

could you please elaborate how this is done?

especially if I need to specify import options?

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}