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):
- 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.
- 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.
- 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.
- If the author is unresponsive, work with the author and email@example.com 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.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||