There are modules on CPAN with the date as the version. For example TableData::Perl::CPAN::Release::Static::2022 is currently at version 20220218.0.

many test machines have it installed

That's interesting because I don't see it indexed either at CPAN or at BACKPAN. Are these your test machines? If so, just uninstall the troublesome module and re-install the correctly-versioned one.

$VERSION variables were inserted only when building a release tarball using Dist::Zilla.

Although I am no fan at all of Dist::Zilla, I still find it hard to believe that it won't/can't just overwrite an existing version with a newer one. Presumably there is a plugin which will do that.

And to address the original question, yes, 4-digit version numbers are fine. Probably any version up to (2^31 - 1) will be OK.

Thanks for the replies. I'll bump the version to 1000.x and make the using modules require that.

@hippo - the reason you can't find the affected versions on CPAN is that I deleted them (via pause). Anyway CPAN *indexed* the releases correctly, i.e. as 3.024 was indexed as 3.024. However once any version with the extra $VERSION declaration is installed on a cpan-testers machine, the test machinery (or maybe cpanm) thinks it has version 999.999 and so won't update it.

For example, see http://www.cpantesters.org/cpan/report/b4581f16-132e-11ee-8887-54486e8775ea

The test fails because "Spreadsheet::Edit::IO version 3.03 required--this is only version 3.022". This should not happen because version '3.030' is a dependency listed in META.yml and so that version (or later) should have been installed. The explanation becomes clear looking further down where it says:

Prerequisite modules loaded:
requires:

    Module                    Need     Have    
    ------------------------- -------- --------
    Algorithm::Diff           0        1.201   
    ...
    Spreadsheet::Edit         3.025    999.999 
    Spreadsheet::Edit::IO     3.030    999.999 <****

The test machine installed v3.022 previously, but now it thinks it has v999.999.

I find this strange, because I was pretty sure that the only way to check the installed version of a module was to load it and call ->VERSION. There isn't any database of package versions within a perl installation that I know of. Are you sure that when you load the published version 3.03 and call ->VERSION it returns '3.03'?

Meanwhile, yes the CPAN tooling does manually parse out your version rather than evaling untrusted code. One thing I have done to solve similar problems (where I needed there to be a version for testing but was injecting the real version as dist build time) was put

# VERSION
$MYPACKAGE::VERSION ||= '999';
[download]

So, let the real one come first, then apply one if it doesn't exist. Maybe just to be *really* sure tooling can't parse the bogus version, you could write it as a harder-to-parse expression, before 'use strict':

package MYPACKAGE;
# VERSION
${ __PACKAGE__ . '::VER' . 'SION' } ||= 2**10;
use strict;
[download]

---

Edit:

Oh! HAH, I remember now, I stopped doing that because I contributed the 'overwrite' option, which allows you to write

[OurPkgVersion]
overwrite = 1
[download]

package MYPACKAGE;
our $VERSION= '999'; # VERSION
[download]

and it just gets overwritten with the real version when released.

Thanks for this extra info - I now understand that it was only the module versions which were incorrect but the dist version was correct. That explains why I couldn't find version 999.999 on CPAN or BackPAN.

However once any version with the extra $VERSION declaration is installed on a cpan-testers machine, the test machinery (or maybe cpanm) thinks it has version 999.999 and so won't update it.

That should only be temporary, I would have thought. See this recent discussion regarding common dependencies not being present on smoke testers' machines. They might not all work this same way, of course - I'm not running a smoke tester (yet) so can't comment further on that. Anyway, you've taken the plunge with the 4-digit major version now so this is all moot.

---

🦛