http://www.perlmonks.org?node_id=11155544


in reply to poll ideas quest 2023

Question/topic
What's a reasonable 'use VERSION' for new CPAN modules in 2023?
Prologue paragraph
This relates to new CPAN modules only. It excludes modules relying on external code; e.g. to support Unicode 13.0, you'd need Perl 5.32 as a minimum. There are a number of versions from which to select, with potential reasons for doing so; these are just suggestions, "Other" is a perfectly valid choice. If you think coding to a preset VERSION is not a good idea, choose "Dynamic".
One or more choices
  • 5.003 (Camel Book 2nd Edition)
  • 5.6 (Camel Book 3rd Edition)
  • 5.8 (stable version for >5 years)
  • 5.10 (many new features now in common use)
  • 5.16 (Camel Book 4th Edition)
  • 5.18 (hash overhaul)
  • 5.26 (no "." in @INC)
  • 5.36 (subroutine signatures)
  • Other (discuss in comments)
  • Dynamic (no standard; code dictates VERSION)


Updates:

— Ken

  • Comment on Re: poll ideas quest 2023 [Reasonable 'use VERSION' for new CPAN modules]

Replies are listed 'Best First'.
Re^2: poll ideas quest 2023 [Reasonable 'use VERSION' for new CPAN modules]
by hippo (Archbishop) on Nov 10, 2023 at 15:38 UTC

    I think I would write the code and then just before publishing run perlver on it and use whatever minimum version that tells me is necessary.

    So, perhaps a "whatever minimum version the code itself requires" option would be useful?


    🦛

      I like the idea of a "whatever minimum version the code itself requires" , but perlver doesn't seem to be the right tool. Sadly, it fails on features. Consider:

      #!/usr/bin/perl $_ = []; my @a = $_->@*; say "@a";
      ----------------------------------------- | file | explicit | syntax | external | | ----------------------------------------- | | perlver.pl | ~ | ~ | n/a | | ----------------------------------------- | | Minimum explicit version : ~ | | Minimum syntax version : ~ | | Minimum version of perl : v5.4.0 (default) | -----------------------------------------

      say requires v5.10 and 'postderef' requires v5.20. For say, even on more recent versions use feature 'say' is required unless use v5.10 is in effect, while 'postderef' is silently available from v5.24 on.

      Greetings,
      -jo

      $gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$
        Sadly, it fails on features

        I was surprised, especially since the changelist shows perlver v1.39 should recognize postderef correctly. So I did some investigation:

        I don't think that passing code that doesn't compile should be expected to work "right" (and calling say without a use feature qw(say) or use v5.10 or newer doesn't compile), but I would expect perlver to complain about non-compiling code.

        If you explicitly use feature qw(postderef); , then perlver will correctly tell you that v5.20.0 is necessary; but you are right that it should recognize that v5.24-onward allow for postfix dereferencing without an explicit feature call, and actually look for the postfix dereferencing syntax.

        I also found that use feature qw(postderef say); will be recognized as needing v5.20.0, but use feature qw(say postderef); will claim it only requires 5.10.0.

        After doing that investigation, I have submitted three bug reports:

      • perlver should die if the script doesn't compile
      • perlver doesn't notice postderef unless it's explicitly called out
      • perlver doesn't notice postderef when combined in use feature list

        New option "Dynamic" covers this — see my reply to hippo.

        I've set up a number of standard Author tests for $work. One of these uses Test::MinimumVersion, which has Perl::MinimumVersion as a dependency. I'm aware of, and have documented, the limitations. Suggestions for something better would be most welcome.

        — Ken

      ++ Thanks for the suggestion.

      I've added "Dynamic" to cover this option; implementation details are intentionally omitted.

      — Ken

Re^2: poll ideas quest 2023 [Reasonable 'use VERSION' for new CPAN modules]
by NERDVANA (Curate) on Nov 10, 2023 at 23:41 UTC

    My just-released CodeGen::Cpppp requires 5.20 because I required lexical subs, and wanted template authors to be able to use sub signatures and 5.20 is the earliest version that supports it. I enable the 'use experimental' for them behind the scenes. I think this is a fairly reasonable target version because it's been out for a long while and there's simply no good way to back-port subroutine signatures if you're advertising them to users of the module.

    Meanwhile, most of my modules will continue to be ~5.8 because 5.8 can do most of anything that needs done, sometimes with some shims to work around bugs. I don't *need* to use subroutine signatures for my own benefit, and indeed they sometimes slow down the code a bit so all the more reason to leave them out of modules if the purpose of the module is performance.

    I don't see any reason to support before 5.8 because I've not heard of a single person still using one of them. Also before 5.8 doesn't have weakrefs, and I consider those to be mandatory for any language that is based on reference counting.

    Edit

    Actually, I'm debating moving all my modules to 5.10 so that I can use //. While I can write that as defined $x? $x : ... the // is cleaner and also more performant.

      I don't see how this relates to the poll idea.

      Did you want a change to the options (or some other aspect of the poll idea)?

      If this idea is accepted (and published) as an actual poll, your post looks more like an explanation of your voting choice in that poll.

      I read what you wrote several times. Am I missing something?

      — Ken

        I guess the points I was raising could be summed up as
        • 5.20 should be included
        • actually 5.20 is sufficient for (basic use of) subroutine signatures, you don't need to depend on 5.36 for that (regarding the comment on 5.36 poll option)
        • do you think anyone will cast a serious vote for less than 5.8?

        And the question on my mind:

        • If I target 5.8 but increase the version any time I *need* a feature from a later perl, am I "Dynamic" or "5.8" or "Other"?