Re-uploading the same version would be a bad idea due to there being multiple instances of a supposedly identical distribution (potentially) out in the wild, which is why even for small documentation changes and the like, you are asked to uprev your module. (2.3633 or higher, in your case).

See https://perldoc.perl.org/perlmodstyle.html#Version-numbering:

Never release anything (even a one-word documentation patch) without incrementing the number. Even a one-word documentation patch should result in a change in version at the sub-minor level.

You wrote:

In PAUSE, under the Utils menu, I came across a "Recent Version" option which looks like it'll do what I want

Do you mean "Reset Version"? I'm not sure how that would help you.

I did mean "Reset Version", my bad. I'll edit my OP.

The premise there is that it will reset the version of the current release version of the software to undef. It allows you supposedly to be able to re-upload the same version again. In my case, I don't think there will be any issues, as the version I want to upload is still the current release, because I've only uploaded a trial version (which the indexer doesn't see) since then.

I'm just running my CI against it now on several fresh new Perl instances. When I'm confident, I'm going to go for it and hope for the best. Worst case scenario, I'll just bump version numbers across the board.

Still scratching my head as to how I missed such a huge (tiny) thing in the first place :)

I'm going through the process of the "Reset Version" function within PAUSE now after correcting the error, testing and creating a new distro (of the same version number). I'm unsure how long this process will take, but I'll record here after it's all done.

I also found the original problem. In most of the test files, I have things like this:

use warnings;
use strict;
 
use lib 't/';
 
use RPiTest qw(check_pin_status);
use RPi::WiringPi;
use RPi::Const qw(:all);
use Test::More;
 
if (! $ENV{RPI_SHIFTREG}){
    plan skip_all => "RPI_SHIFTREG environment variable not set\n";
}
 
if (! $ENV{RPI_MCP3008}){
    plan skip_all => "RPI_MCP3008 environment variable not set\n";
}
 
if (! $ENV{PI_BOARD}){
    $ENV{NO_BOARD} = 1;
    plan skip_all => "Not on a Pi board\n";
}
[download]

That ensures that only my hardware test platform (or any user who has these environment variables set) will have the tests within the specific test file executed.

However, I was testing something briefly with a single test file, and instead of unsetting the env var, I commented out all three "skip_all" lines. After I was done, I forgot to uncomment them.

Because the system I was testing on had those variables set, it would skip over all three if() lines and run the following tests. If I had of ran my tests on a system without those env vars set, I would have hit on the issue prior to release.

Moral of the story... ensure that I test on both my normal test platforms, and a clean system without my test environment variables set... or, test things like this in a proper way, instead of commenting out test file lines arbitrarily.

The "Reset Version" on PAUSE doesn't work as I had hoped. Although it resets the latest version indexed just fine, it won't allow an upload of the same distribution file name again. Deleting on the PAUSE takes ~4 days, so deleting the original file first is out of the question.

I just bumped the version number and uploaded. At least I tried to find a way to keep things clean.

According to the PAUSE upload page, deleting a file from PAUSE also blacklists its name, permanently, for security reasons. You could still delete the file to "withdraw" the broken release, but you probably will not be able to upload a replacement for the "same" version.

Thanks jcb, I was just curious. Know I know for sure.