Re^2: Determining minimum Perl version for new module

You're the only person who has made decisions on what features of Perl you require.

Agree! But sometimes a little outside discussion can help refine those decisions, so thank you for entertaining said discussion. :-)

Comment on Re^2: Determining minimum Perl version for new module

Replies are listed 'Best First'.
Re^3: Determining minimum Perl version for new module by stevieb (Canon) on Sep 12, 2019 at 01:57 UTC
If that's the case, I say require `5.10`. For me personally, it'd cover my `5.8` standard, and any requirement above that. The CPAN Testers will ensure things work correctly against your required version of Perl, as should your local testing. If not, might I suggest the following: test against numerous versions of `perl` via perlbrew or berrybrew ensure that your software works against any custom libraries you have locally verify that any local security validation is either workable or bypassed in testing document and criticize any client data that you've tested against, sanitize after digesting it, and request client feedback on its handling Beyond that, just have numerous test platforms to run against that you can reset on every test run. There's no way to validate everything every time, so use your best judgement. If your platform is useful and there's an issue found, make sure you have very accessible contact information.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Determining minimum Perl version for new module
by stevieb (Canon) on Sep 12, 2019 at 01:57 UTC

If that's the case, I say require 5.10. For me personally, it'd cover my 5.8 standard, and any requirement above that.

The CPAN Testers will ensure things work correctly against your required version of Perl, as should your local testing. If not, might I suggest the following:

test against numerous versions of perl via perlbrew or berrybrew
ensure that your software works against any custom libraries you have locally
verify that any local security validation is either workable or bypassed in testing
document and criticize any client data that you've tested against, sanitize after digesting it, and request client feedback on its handling

Beyond that, just have numerous test platforms to run against that you can reset on every test run. There's no way to validate everything every time, so use your best judgement. If your platform is useful and there's an issue found, make sure you have very accessible contact information.

[reply]
[d/l]
[select]