Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

What's your preferred 'use VERSION' for new CPAN modules in 2023?

by kcott (Archbishop)
on Dec 01, 2023 at 17:12 UTC ( [id://11156014] : poll . print w/replies, xml ) Need Help??

Vote on this poll

5.003 (Camel Book 2nd Edition)
[bar] 0/0%
5.6 (Camel Book 3rd Edition)
[bar] 6/9%
5.8 (stable version for >5 years)
[bar] 4/6%
5.10 (many new features now in common use)
[bar] 12/19%
5.16 (Camel Book 4th Edition)
[bar] 3/5%
5.18 (hash overhaul)
[bar] 2/3%
5.26 (no "." in @INC)
[bar] 2/3%
5.36 (subroutine signatures)
[bar] 11/17%
Dynamic (no standard; code dictates VERSION)
[bar] 18/28%
Other (discuss in comments)
[bar] 6/9%
64 total votes
  • Comment on What's your preferred 'use VERSION' for new CPAN modules in 2023?
Replies are listed 'Best First'.
Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by parv (Parson) on Dec 01, 2023 at 18:28 UTC

    Voted for v.5.36 one.

    Yet, yet ... had to make do without the sub signatures😫: changed the original to work with perl v5.18.2 in WSL (original; Ubuntu 14.04🖕) on Windows 10.

    Cannot wait when Windows 10 would cease to get security updates (20251014 it is⏳) for me to then run FreeBSD on bare metal than in a VM. Would have been happier if could update that to at least v5.20.

Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by Bod (Parson) on Dec 02, 2023 at 13:27 UTC

    I've voted for 5.10 as that is my default...

    However, it is a bit dynamic as it will change depending on the code. If it is a very simple module from a code perspective, I'll wind it down, whereas if I need more recent features, I'll wind it up.

    But - I never specify above 5.16 as quite a few shared hosting providers are stuck with this version of Perl and I mostly write modules to run on webservers.

Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by duelafn (Parson) on Dec 01, 2023 at 21:03 UTC

    Technically "Other": use 5.028; use experimental 'signatures';

    I want the signatures, but 5.36 is still a bit too new for all my uses. (5.28 due to the subroutine attribute / signatures order change)

    Good Day,
        Dean

Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by eyepopslikeamosquito (Archbishop) on Dec 02, 2023 at 00:49 UTC

    While I like to reach the widest possible audience with a CPAN module, I cannot bring myself to write any Perl code without at least these basic features:

    👁️🍾👍🦟
Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by NERDVANA (Deacon) on Dec 02, 2023 at 01:17 UTC

    Heh, even after the discussion on the poll proposal, I still don't know what the right answer is for me.

    I gave it a deeper review this time. Out of my 30 CPAN modules

    • Undeclared - 16x
    • 5.6 - 2x (because they extend Log::Any, which requires 5.6)
    • 5.8 - 4x (usually due to Scalar::Util::weaken, or some kind of unicode reason)
    • 5.10 - 3x (endian pack, or // in a hot path)
    • 5.14 - 3x (all part of the same ecosystem, and I don't remember why!)
    • 5.20 - 1x (my sub was crucial to the design)
    • 5.36 - 1x (it's a web app, not a module you'd depend on, so just run the latest perl in a container if you need to)

    For the undeclared majority, I leave them undeclared because I want CPAN Testers to find out the minimum version for me. Next time I'm adding a feature, I check testers to see if there's an obvious change I can make to extend compatibility. A majority of these modules now support back to 5.8, and a few even handle 5.6, or maybe even earlier because that's where cpan testers stops, and I've never had a working copy of 5.5 or earlier. Some, I don't even know, because they depend on special C libraries that aren't available on most smoke testers, but I probably tested them locally with 5.8 or 5.10, depending whether I was developing on my laptop or desktop. (I couldn't get perlbrew 5.8 to install on my laptop for reasons I never tracked down)

    I answered 5.8 in the poll because that's where I stop caring.

Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by pryrt (Abbot) on Dec 01, 2023 at 17:44 UTC
    I've always aimed for a "pretty old" version for CPAN modules. When I first started on CPAN, I was taking over an existing module which had 5.6-compatibility, so that was my original default.

    As my own skills have improved, I moved to about 5.10, because I use defined-or a lot. And also because 5.10 was easier to have a test suite on Windows (both my personal machines and free CI services).

    Recently I've started making use of non-destructive substitution (s///r), though I don't think that's made it into any of my CPAN modules -- if I start a new module, at this point I'm likely to pick 5.14 just to make sure I won't accidentally use that feature without declaring it.

    Auditing my handful of modules, two are 5.06, one 5.08, two 5.10, and one 5.12.

Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by Tux (Canon) on Dec 02, 2023 at 16:03 UTC

    I have 3 x 5.6, 1 x 5.6.1, 3 x 5.8.0, 2 x 5.8.3, 1 x 5.8.6, 2 x 5.10, 1 x 5.12, 4 x 5.14, and 2 x 5.14.2 in my CPAN releases where I like to keep it as low/old as possible.

    For all scripts that should work on AIX, HP-UX, Solaris and other non-mainstream *nix OS's, I require 5.14.2.

    For anything that requires a fun factor, I won't go below 5.12: I want both $c //= 42; and my $x = $y =~ s{foo\Kbar}{dwok}r;


    Enjoy, Have FUN! H.Merijn
Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by cavac (Parson) on Dec 05, 2023 at 07:31 UTC

    No "new" CPAN modules in the works at the moment, but Net::Clacks already uses 5.36 due to the switch to subsigs.

    A lot of my internal ("DarkPAN") code also already switched to 5.36 (planning for 5.38 soon). It's a lot easier for development in a small team if you can set just a single Perl version your software has to be compatible with. Generally, i support Perl current-stable and previous-stable, similar to p5p. When subsigs came out of experimental, this was huge enough to switch basically immediately and rework my huge code base to use subsigs.

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP

      G'day cavac,

      "... Net::Clacks already uses 5.36 ..."

      Might I suggest that the documentation for this module clearly states that.

      Also consider adding MIN_PERL_VERSION to the Makefile.PL. I believe that will ensure 'make' fails and a subsequent 'make test' will not be attempted — see the only current Cygwin "Report for Net-Clacks-27" for an example of multiple tests failing with "Error:  Perl v5.36.0 required...".

      More driven by a love of Discworld 😍 than any particular need for this module, I attempted to install it using four different Perl versions. When "CPAN Testers Matrix: Net-Clacks 27" is next updated, you should see three green (PASS) and one orangey (NA) swatches, in the Cygwin column, for versions v5.39.3, v5.38.0, v5.36.0 and v5.34.0, respectively.

      — Ken

        Thanks, will do! Now i have another reason to release a new version. Guess that's another excuse down the drain not to do any open source work over the holidays ;-)

        PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Re: What's your preferred 'use VERSION' for new CPAN modules in 2023?
by BillKSmith (Monsignor) on Dec 27, 2023 at 14:47 UTC
    In private modules, I prefer to specify the required features rather than a version which supports them, but the question explicitly specifies CPAN. Lacking a strong preference for any of the other choices, I voted for 'dynamic'. Perhaps, we should agree on a convention.
    Bill

View List Of Past Polls