I looked into the META files issue a bit more.

I couldn't find the old post that your "META" comment reminded me of, exactly. (It may have been Re^3: What to test in a new module, but that was you calling it "META files" when it was actually talking about the META_MERGE parameter to MakeMaker, which defines some of the info that goes into the META.json/yml files. I thought maybe you had mentioned that copy back-and-forth before, but I cannot find it when I search your recent posts with "META". or it could just be that when you made the comment in this discussion, my mind invented a vague memory of some previous comment by you about having to do weird copy of META files. Sorry if my last post had a reply to a figment of my imagination.)

So I actually downloaded your repo, and went through the standard incantation:

perl Makefile.PL
gmake disttest
gmake dist
[download]

I then looked at the Re: What do I use to release a module to CPAN for the first time? post you linked to, and saw that step13 claimed you needed to copy the META.json/yml files to your main directory and manually adding those two files to the MANIFEST before doing the gmake dist : all of my experience and my experiments today say that is unnecessary. If I just follow the incantation above, then look in the .tar.gz, the META.json/yml are properly there -- I did't have to copy those files. Follow the standard incantation yourself, and see if you can see those files were properly created: if they do get created, then you can skip step 13 in your future releases, saving you time and effort. If not, please show the output from your sequence that you follow, and show the contents of the .tar.gz that is created.

Follow the standard incantation yourself, and see if you can see those files were properly created

Done!
And it seems to work fine 😃

META.json/yml are missing from the working directory but presence in the .tar.gz file. Only MYMETA.json/yml are in the working directory but they appear to have the same contents...

{
   "abstract" : "Crop and resize an image to create a square image",
   "author" : [
      "Ian Boddison <bod@cpan.org>"
   ],
   "dynamic_config" : 1,
   "generated_by" : "ExtUtils::MakeMaker version 7.58, CPAN::Meta::Con
+verter version 2.150010",
   "license" : [
      "perl_5"
   ],
   "meta-spec" : {
      "url" : "http://search.cpan.org/perldoc?CPAN::Meta::Spec",
      "version" : 2
   },
   "name" : "Image-Square",
   "no_index" : {
      "directory" : [
         "t",
         "inc"
      ]
   },
   "prereqs" : {
      "build" : {
         "requires" : {
            "ExtUtils::MakeMaker" : "0"
         }
      },
      "configure" : {
         "requires" : {
            "ExtUtils::MakeMaker" : "0"
         }
      },
      "runtime" : {
         "requires" : {
            "Carp" : "1.45",
            "GD" : "2.13",
            "perl" : "5.010"
         }
      },
      "test" : {
         "requires" : {
            "Test::More" : "0"
         }
      }
   },
   "release_status" : "unstable",
   "version" : "0.01_4",
   "x_serialization_backend" : "JSON::PP version 4.06"
}
[download]

That's from my local copy before the GitHub META_MERGE PR

The MYMETA files are created by perl Makefile.PL and are cleaned up by the gmake clean that you do at the end; they don't need to be in the distro itself (which is why gmake dist doesn't include them)

No-one else mentioned this: don't put "author" or "release" tests in t. An environment variable is not an adequate guard. Put them in xt and run them yourself before making a release (and in a job on your CI so you catch anything that breaks them immediately).

The meaning of "first" is my quibble. If by "first", you mean "before I've done a initial public release", I have no problem with that (though I've never done that on my handful of CPAN modules, and don't remember seeing that advice). If by "first" you mean "before I've thoroughly tested my distribution", I would vehemently disagree with that understanding. :-)

By "first" I mean after testing but before the public release...
However, until today, I wasn't aware that I could test a module in multiple environments other than spinning up a virtual environment. Given that this module is both passing and failing on Linux under the same version of Perl according to the test results, I figured I would have to spin up so many variations that it would be impossible, or at least impractical. Compounded by my servere lack of in-depth Linux knowledge.

Those who want a pre-release can install a pre-production module from GitHub, it doesn't have to be on CPAN for that.

The module was released to CPAN before it was uploaded to GitHub. Other than for Pull Requests, I've yet to see how GitHub is useful for Perl as people install them from CPAN. Given the number of Monks who use it and have advised me to do the same, I total accept it's the right way to go but I don't totally understand why yet.

I tend to do the development locally, test through example scripts, test through test files and prove them. Package and upload to CPAN then think about GitHub a few days later!

I vaguely remember being highly curious why you needed to do that, the last time you mentioned it, but didn't have time at that point to look into it, and I had probably hoped that someone else would disabuse you of that need.

I copy the META files because that's what's it says to do in Re: What do I use to release a module to CPAN for the first time?

Like I said earlier, I don't understand why I copy them or what they do. I really should but there is always something more pressing and, as it works, it is low priority to find out why it works...

Merge the CI environment I gave in the PR, and watch it fail

I've merged the META_MERGE Pull Request. My first time dealing with a PR from that end...I did one on Module::Starter under the excellent guidance of hippo but then heard nothing more. I'm looking at the CI PR now and will try to understand what it does and what I do with it!

I feel really weird giving advice like this. I'm just an amateur with a few CPAN modules that, as far as I know, no one but me uses (okay, I know of one other user of one of my modules, but one real user is statistically zero compared to CPAN norms). I'm not sure why anyone would trust any of my advice. And I definitely make no claim that it's "best practices".

I learnt a long time ago that you don't need to be very much further ahead to give valuable advice. Many times it's better if you are not too far further down the learning road as you haven't forgotten the challenges everyone goes through. Regardless of how weird you feel, your help is very much appreciated 👍

Other than for Pull Requests, I've yet to see how GitHub is useful for Perl as people install them from CPAN. Given the number of Monks who use it and have advised me to do the same, I total accept it's the right way to go but I don't totally understand why yet.

It's exceptionally useful. It allows us to fork and clone your project and review/modify/test it locally, in our own environments. It's far less time consuming then downloading a tarball, extracting it, playing with it, then creating patches to send you for possible inclusion. You seem to be in the mindset that devs just want to install your software. We don't. Often we don't want to install it at all, just want to look at it.

Also, as pryrt mentioned above, you get Github Actions to perform automated CI testing on every push to the repo. This is infinitely handy. (A couple of years ago I switched all of my projects to Github Actions from Travis CI). It also allows you to easily revert changes, find when specific changes were made (and by who), run multiple concurrent branches simultaneously then merge the changes from those branches into your main branch once they're tested and stable etc. The version control system is far more useful to yourself than it is outside users of your software, but it is very useful to them too, regardless of the language in use.

Your workflow should begin with the Version Control System, not be an afterthought. Once you've gotten into this workflow process, you'll begin to clearly see how and why it is so important.

Update: Here's one of my basic Github Actions configuration files. It's a file called .github/workflows/github_ci_default.yml in the root of one of my repositories. Do some reading on Github Actions. It'll be worth your time.

Merge the CI environment I gave in the PR, and watch it fail

I did watch - and observed something I had not seen before!

It fails on the horizontal image and passes on the vertical image...both on Ubuntu and Windows