The slow painful drip of backward incompatible changes only affects you if you upgrade. And I would say that the minor (but breaking) changes are mostly minor changes, but we feel them as nasty because we (as a part of the community) have the expectation that our scripts from back then (be it Perl 4, or Perl 5.005_03 or Perl 5.12) still work unchanged.

I also don't see it as "p5p vs CPAN", because I would say that all participants on perl5-porters deeply care about keeping (modules on) CPAN working well and work with module authors to keep the breakage introduced through changes low. Bugward compatibility takes a backseat to correctness for example.

But looking at it from a different perspective, it is great how much of it still works after 20 years of changes. So it's not all doom and gloom in my opinion.

There are many ways to publish your patches instead of keeping them locally. In ascending order of utility (but also, descending order of ease, unfortunately):

1. Publish the changed repository on Github or wherever. This has the advantage of not even needing a CPAN account. The disadvantage is obviously that nobody will find your patches.
2. Publish the patch as a CPAN::Distropref in your own CPAN directory. This has the advantage of getting the patch applied automatically whenever you (re)install the distribution. The disadvantage is still that nobody will find your patch and the reasons for why you made it. But at least they can install a module that will find them.
3. Open a ticket on the issue tracker for the module and attach the patch there. This has the benefit that others who encounter the problem will see the problem, and they can apply your patch locally. Also, I've often (re)found my patches in tickets when (re)installing a fresh Perl version. Maybe the author wakes up and incorporates your patch into a fresh release.
4. If the author is unresponsive, work with the author and modules@perl.org to adopt the module or get co-maintainership. Then, incorporate your changes and release a new version. I'm currently in the process of doing that with Spreadsheet::ReadSXC. This is a slow process as everybody involved has other priorities and you should look at this in a timeline between 3 months to years until progress happens. The upside is that once you are the new maintainer, you can put out the new release with your fixes and maybe the accumulated fixes from the bug tracker (or forks) as well. Ideally you also add other people as co-maintainers on CPAN so that you don't become the next single point of failure.

Update: Fixed description of how the list was sorted.

I also don't see it as "p5p vs CPAN", because I would say that all participants on perl5-porters deeply care about keeping (modules on) CPAN working well and work with module authors to keep the breakage introduced through changes low. Bugward compatibility takes a backseat to correctness for example.

I agree; they're pretty rigorous at investigating how changes affect CPAN modules. That doesn't mean they won't make the changes anyway, if they're overall beneficial, but they seem to avoid module breakage pretty well.

An optimization for how constants were put into the stash in one of the 5.27.x broke the Type::Tiny test suite (and also Role::Tiny and Variable::Magic, I believe). They backed it out and worked with module authors, providing patches and additional test cases, before rolling it back into the 5.27.x code ahead of the stable 5.28.0 release.

toby döt ink

> Bugward compatibility takes a backseat to correctness for example.

This is the problem. The perfect (p5p) is the enemy of the good (CPAN). How can it be acceptable that "fixing" Perl is "breaking" CPAN? I noticed the breaking changes tend to reduce the DWIM nature of perl in favor of some abstract notion of what is correct, like for example, my $foo qw(bar baz) makes perfect sense and was valid perl until some programming justice warriors decided that breaking backcompat was less important than their idea of programming correctness.

The result is broken scientific distros sitting on CPAN forever because, for example, we now have to --force install and add 2 characters to 1 module to fix 3 modules. Someone who is more of a scientist than a perl programmer will shrug their shoulders and move on to a programming language with working libraries. It's a dire situation!

Thank you Corion and daxim for your thoughtful replies and valuable information (but that anonymous reply, get an account! =)

like for example, my $foo qw(bar baz) makes perfect sense and was valid perl until

I'm afraid to say that it doesn't make perfect sense to me. What would you expect it to mean?

It's also not valid perl, even on the oldest one I could find:

$ perl -v

This is perl, v5.8.8 built for i386-linux-thread-multi

Copyright 1987-2006, Larry Wall

Perl may be copied only under the terms of either the Artistic License
+ or the
GNU General Public License, which may be found in the Perl 5 source ki
+t.

Complete documentation for Perl, including FAQ lists, should be found 
+on
this system using "man perl" or "perldoc perl".  If you have access to
+ the
Internet, point your browser at http://www.perl.org/, the Perl Home Pa
+ge.

$ perl -e 'my $foo qw(bar baz)'
syntax error at -e line 1, near "$foo qw(bar baz)"
Execution of -e aborted due to compilation errors.
[download]

The result is broken scientific distros sitting on CPAN forever because, for example, we now have to --force install and add 2 characters to 1 module to fix 3 modules.

I am no advocate for breaking backwards compatibility but a seemingly trivial change to a module which moves it from unusable to working on modern perls is something any module maintainer should be doing. Just not necessarily in the next half hour. If there's no repsonse to such tickets in a reasonable time-frame (give them a few weeks at least) then it's probably abandoned and a good candidate for a take-over.

In that case, it was always a bug, it just wasn't reported by Perl as such.

If you want more "influence", consider becoming a part of p5p. It's as easy as reading the mailing list and/or writing a mail to it:

• perl5-porters archive
• Submit bugs to it via perlbug

Please note that these are all volunteers, so taking a belligerent stance may not get your case heard in the way you want. But if you are interested in actually fixing the problems, I'm sure you will be welcome there.

Could you list some of the broken distros? There might be simple fixes that others could implement.

CPAN modules that get broken

• the cpXXXan software
• blead breaks cpan emails on p5p

by visiting CPAN and clicking Testers on broken modules but wonder if someone has scraped that

I'm fixing broken orphaned modules locally with no way help fix the official and CPAN is in an advanced state of decay.

Imagine how fast the 1/2 of CPAN that is probably broken would be fixed!

Re: p5p vs CPAN : Is there a list of modules broken by backward incompatible changes?

Hi,

What did the perl5-porters have to say bout this?

Did you use the same charm when you asked them?

On second thought, reap the OP for floating