Skip to main content

mastodon - Link to source

I have decided that any new releases of existing #CPAN modules that I make will now be bumped up to needing at least perl 5.20 (except in a few odd cases).

This means they can now all use a bunch more new features such as signatures. The benefits purely on line-count, readability, and the basic argument checking that it gives, already seem worth it.

Already any new dists I make tend to be 5.36+ or 5.38+ if using `class`; but this now applies to existing ones as well

#perl

#perl #cpan
in reply to Paul Evans

Bartosz Jarzyna
mastodon - Link to source
Bartosz Jarzyna
• •
if your module is a dependency for other modules, and those modules require pre-5.20, then you will bump their minimum perl versions to 5.20 too. No way to set maximum version of a dependency, so it will technically still require older version, but in practice will only be installable on that perl version if your module is manually installed in an older version. Just saying.
in reply to Paul Evans

Paul Evans
mastodon - Link to source
Paul Evans
• •
So many updates along similar lines as this. Just little neatening updates that remove some of that annoying argument-handling noise.
Two diff chunks in two `sub`s of Perl code. Each removes the `my $self = shift; my %args = @_;` lines, and replaces them with the addition of the `( $self, %args )` parameters in the signature. Each chunk is thus two lines shorter and has less visual noise.
Unknown parent

Bill Ricker
mastodon - Link to source
Bill Ricker
• •

@menos @bbrtj
The folks who can't update Perl in production but can update CPAN modules in production is a Venn diagram with non-null but small overlap. If this nudges them to build a new Perl, that's a good thing.

(And if they'd avoided using /bin/perl as we've advised for literally decades they'd be free to update, *sigh*.
I preached this inside Fortune 500 from FLOSS Governance board for a decade, over a decade ago ... not everyone listens, tho'.)

@Bartosz Jarzyna @Matt
in reply to Bill Ricker

Matt
mastodon - Link to source
Matt
• •
@BRicker @bbrtj TBF packaging your own Perl for old systems can be a daunting task for a lot of people. But if your system Perl isn't at least 5.20 it means you're running network services (in our case at least) on an OS that hasn't been patched in years and "I can't update" is about as serious an argument as "I don't know how to change my car's brake pads".
@Bill Ricker @Bartosz Jarzyna
in reply to Matt

Bill Ricker
mastodon - Link to source
Bill Ricker
• •
@menos @bbrtj
Pretty much yes. If one doesn't have (aren't allowed) a cc, even Perlbrew won't work.
But if they aren't updating OS even once decade (due to misplaced middlemismanagement riskaversion or tightwadness etc) why would they need latest CPAN update?
That's what makes the actual impact a narrow Venn diagram: app devs continuing to develop an app despite OS being frozen for ^reasons^. Those few have to be content with old modules too.
@Bartosz Jarzyna @Matt
in reply to Bill Ricker

Bill Ricker
mastodon - Link to source
Bill Ricker
• •
@menos @bbrtj
As a community we bend over backwards not to break old code with new releases of Perl, modules.
But if they aren't taking advantage of the non-breaking by new Perls, they can't expect new module updates to not use decade old Perl features! Paul's split of 5.20 for his module updates and 5.3x for his new shiny Classy ones is a good balance.
@Bartosz Jarzyna @Matt
⇧