Sending a dev version to CPAN before there's a released version makes it really hard for us to find your project and the cpantesters results for those dev versions, as kcott mentioned, because the distribution isn't in the publicly-searchable distros. For other readers of this thread, this link will get you to v0.01_4 in metacpan, and if Bod releases further dev releases before a full release, you can use the pulldown from there to look for other dev releases. Similarly, this gets you to the cpantesters matrix for 0.01_4, from which you can get to the other dev-release test results or the log.txt results for tests that have been submitted but not merged into the main interface.

In my personal opinion, doing a dev release to CPAN without an initial release without having at least done your own suite of multi-environment testing borders on abusing the cpantesters network -- if you've don't your own multi-environment testing, and have previously had a successful initial release, then if cpantesters show a strange error in an environment that you don't have access to testing, then I can understand doing a dev release to CPAN before my next release (and in fact I've done that on my projects in the past), but it shouldn't be your first line of defense.

With free Continuous Integration testing available through GitHub Actions and places like Appveyor, there's no reason for not doing a suite of tests long before any release or dev-release to CPAN, on at least Ubuntu and Windows (I haven't done any macos testing, though I forget whether that's just because I haven't tried, or because I've tried but failed; I've still got a personal TODO for freebsd and similar through a GitHub action, because those platforms are often the edge cases for my modules, but I ran into some difficulties, and it's been a low priority for me).

And as a final small piece of advice: always include the META_MERGE in your Makefile.PL (removing it for older versions of MakeMaker that don't understand that syntax), so that people can easily navigate from the metacpan page for your distribution to the repo and issues -- once I did find your results and metacpan entry, I then had to come back here to find your link to your repo.

Coming soon: links to the issues and PR I have to help you understand/implement CI and META_MERGE. The CI PR will come complete with showing your tests failing, presumably for the same mismatches that the cpantesters have been reporting.

update 1 : add links:

update 2 : added "first line of defense" phrase.

In reply to testing/release advice [was: Stopping tests] by pryrt
in thread Stopping tests by Bod

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.