Very nice write up. I hope others adopt this style as well. I do have a couple of comments however.
The first is that your travis.yml is very involved and perhaps a simpler example is less daunting up front. For example, this is what i tend to use
language: perl
before_install:
- cpanm --notest Test::Pod Test::Pod::Coverage #other dependencie
+s you have
perl:
- "5.22"
- "5.18"
- "5.14"
- "5.8"
Travi-CI tends to allocate 4 workers at a time, so specifying more than 4 Perls will significantly increase the time it takes to complete the entire job. Just something to consider. More here:
https://docs.travis-ci.com/user/speeding-up-the-build/, but i have tried none of those examples. I am quite happy with the amount of time it takes, this is a free service after all. :)
The second comment i have regards the adding of badges to POD. I do not recommend this. Instead I recommend adding any and all badges to your Github readme file and specify the Github repository in your distribution's Makefile:
META_ADD => {
resources => {
homepage => 'https://github.com/user/Foo-Bar,
repository => 'https://github.com/user/Foo-Bar.git',
},
}
... or your
Build file. Consult the docs for more. The reason i say not to put build badges inside your CPAN distros is because they reflect the state of the Github repo, not the distro on CPAN. You can also add a badge to your Github
readme file that points to your (already registered) CPAN module. :)
[](https://metacp
+an.org/pod/Foo::Bar)
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
