Re^3: Deciding dependency versions

"I rely on Makefile.PL do specify the minimum Perl version."

I didn't think that would be enough, so I ran some tests.

ken@titan ~/tmp/pm_11152747_min_ver
$ module-starter --module=Bod::Min::Ver
...
Created starter directories and files

$ cd Bod-Min-Ver

# Modified lib/Bod/Min/Ver.pm
package Bod::Min::Ver;

#use v5.36; <--- commented out

our $VERSION = '0.001';

print "$^V\n"; <--- newly added

# remainder unchanged

$ cat Makefile.PL
...
   MIN_PERL_VERSION    => '5.036',
...

$ perlbrew switch perl-5.34.0

$ perl -v | head -2 | tail -1
This is perl 5, version 34, subversion 0 (v5.34.0) built for cygwin-th
+read-multi

$ perl Makefile.PL
Checking if your kit is complete...
Looks good
Warning: Perl version 5.036 or higher required. We run 5.034000.
Generating a Unix-style Makefile
Writing Makefile for Bod::Min::Ver
Writing MYMETA.yml and MYMETA.json

$ make
cp lib/Bod/Min/Ver.pm blib/lib/Bod/Min/Ver.pm
Manifying 1 pod document

$ make test
...
t/00-load.t ............. Perl v5.36.0 required--this is only v5.34.0,
+ stopped at t/00-load.t line 3.
... all other tests failed in a similar fashion ...

$ perldoc lib/Bod/Min/Ver.pm
... POD template shown correctly ...

$ perl -e 'use lib "./lib"; use Bod::Min::Ver'
v5.34.0
[download]

So, `perl Makefile.PL` only provides an advisory warning, and module can still be loaded with a Perl version earlier than MIN_PERL_VERSION.

Recommendation: include "use VERSION;".

"Is there any data anywhere on how many people are actually using really old versions of Perl?"

It's possible that there's usage information somewhere, maybe from some sort of survey, but I'm unaware of such; perhaps another monk knows.

My guesses would be (mostly based on SoPW posts that I remember):

5.6 and earlier: a very small number; mostly academic interest and hobbyists.
5.8 & 5.10: there seems to be a small number of ISPs, with minimal Perl support, who provide these versions.
5.12 and later: probably depends on whether you categorise these as "really old versions". My "Out-of-the box Perl version - lowest common denominator" post, from a couple of years ago, may provide some insights.

"Does CPAN collect it from install requests?"

That seems unlikely. After downloading a module tarball (which may not even involve Perl) there's no further interaction with CPAN directly.

— Ken

Comment on Re^3: Deciding dependency versions Select or Download Code

Replies are listed 'Best First'.
Re^4: Deciding dependency versions by Tux (Canon) on Jun 11, 2023 at 11:00 UTC
Older versions of perl (where old is very relative) will also be seen a lot on EOL Os's and OS releases where the (end-)user has no means to update/upgrade to a newer release. This includes OS's like AIX, HP-UX, Solaris, and Irix (and a lot of others) that still run production code but do not support major updates/upgrades for vital software. Sometimes life sucks. Enjoy, Have FUN! H.Merijn	[reply]
Re^5: Deciding dependency versions by Bod (Parson) on Jun 11, 2023 at 11:51 UTC
Older versions of perl (where old is very relative) will also be seen a lot on EOL Os's and OS releases where the (end-)user has no means to update/upgrade to a newer release Good point! Not that I need to worry about it right now as all the modules I am creating connect to web API's so they are useless on an installation with no means to update. But I'm sure I won't always write API modules!	[reply]
Re^4: Deciding dependency versions by Bod (Parson) on Jun 11, 2023 at 12:12 UTC
I didn't think that would be enough, so I ran some tests Thanks kcott. Very much appreciated that you took the time to test it. Do you feel it is worth shipping an update to include `use VERSION` or am I relatively safe to wait until another update is needed? 5.8 & 5.10: there seems to be a small number of ISPs, with minimal Perl support, who provide these versions Very timely as this morning I've had a FAIL from CPAN Testers :( After some investigation, it seems that I've used the defined-or operator that was new in `v5.10`. So, now I have to decide whether to support a 16-year-old version of Perl or set the minimum version at `v5.10`. If it wasn't a "small number of ISPs" that are using `v5.8` then it would be an easy choice as the module is useless without an active network connection to call the APIs. I was very surprised to note the time between `v5.8` (2003) and `v5.10` (2007) This has also got me looking back at Business::Stripe::WebCheckout where there have been some N/A CPAN Tester reports. I'd thought that was because of the minimum Perl version but it isn't. Instead it seems to be that the tester didn't have the required version of ExtUtils::MakeMaker installed so didn't run the tests. This module would also fail on Perl `v5.8`... Interestingly, the Wikipedia article on Perl version lists `v5.16` onward as "toolchain" and `v5.14` backwards as "legacy". So a case could certainly be made to not support anything prior to `v5.16`.	[reply] [d/l] [select]
Re^5: Deciding dependency versions by kcott (Archbishop) on Jun 11, 2023 at 14:09 UTC
I hadn't encountered the idea of "rely on Makefile.PL" previously. As I said, "I didn't think that would be enough", but I didn't know for sure. The tests were as much for my benefit as yours. I was surprised that I only got a warning re Perl version. I have the impression that you're in the process of providing other updates for your module. I'd be inclined to include "`use VERSION;`" with the next set of updates. From `v5.12` onwards, new versions have been released annually (mostly in May or June); in general, `v5.x.y` versions (where x is even and y > 0) have been compatible with `5.x.0`, the few exceptions (just 3 or 4, I think) have only had minor incompatibilities. `v5.10.1` was incompatible with `v5.10.0` (from memory, mostly, or perhaps entirely, due to the '`~~`' operator). `v5.8.0` to `5.8.9` were more like a series of completely new releases, which is why they're spread over a longer period than we're currently seeing — I recall working remotely a lot during that period and was bitten a few times with code that worked on the `v5.8.x` that I had installed at home, failing on the `v5.8.x-1` that was installed at $work. I suppose people will have their own views on where legacy ends and toolchain begins. I currently have to support `v5.14` for $work; but that's planned to change to `v5.26` in the not-too-distant future. I have seen a minimum version for CPAN modules hotly debated whenever the topic comes up: it won't matter what you choose; it's likely someone will disagree with it. — Ken	[reply] [d/l] [select]
Re^6: Deciding dependency versions by Bod (Parson) on Jun 11, 2023 at 16:40 UTC
v5.8.0 to 5.8.9 were more like a series of completely new releases I have seen a minimum version for CPAN modules hotly debated whenever the topic comes up: it won't matter what you choose; it's likely someone will disagree with it. Thanks Ken, That's given me the information and nudge I needed to make up my mind about the minimum Perl version...my default level of support for modules designed to run on the web and make API calls will be `v5.10`. That way, I don't need to start remembering (and more likely forgetting!) about sub-versions of `v5.8.x`. If I really need a newer feature then I will look at this again for just that module but until that happens or I write a module that isn't going to run on the web, that's one bit of decision making boxed off 😃 Perl version decided...now, that jut leaves dependency version But there is plenty of information in this thread for me to go over and digest...	[reply] [d/l] [select]