The CPAN has improved Perl in many ways, but it's exposed other problems.
If you know how to use the CPAN, you can install and upgrade modules and distributions. This is great for users. You get new features and new capabilities, and sometimes you can even change how Perl works internally, without having to upgrade Perl itself. That's great for the core developers, because people can experiment with new features and ideas and even syntaxes and dialects without changing the core.
Everything is great... except for the unforeseen repercussions.
Someone discovered a bug in a core library, and wanted to release a new version without forcing people to upgrade all of Perl and all of their libraries at the same time. In general, that's a good policy.
Someone decided that a CPAN module was so widely-used that it belonged in the core. I can see how that argument works. It's certainly worked on lots of modules in the past.
Someone said "That's great that this is in the core, but someone's paying me to use it with an older version of Perl, so I refuse to tie its syntax or feature set or capabilities to only those which the current development version of Perl provides." I can understand that desire.
None of these are bad ideas in and of themselves, but the consequences are poisonous together. The chosen solution to one problem was to maintain a core module somewhere outside of the core, where the Perl 5 porters weren't the people responsible for day-to-day maintenance, and to release new versions to the CPAN as they were ready, and to juggle the release schedule with the release schedule for new versions of the Perl core, which should always contain the newest versions of core modules available, even if those modules live elsewhere and have already had releases elsewhere.
Imagine trying to coordinate the release of the core language and half a dozen dual-lived modules. Now imagine trying to coordinate the release of the core language and several dozen dual-lived modules.
Now there's a big snarled shoelaces problem and we don't know anybody named Alexander.
Did I mention that some of these modules have to run on various versions of Perl, unmodified? (I spent a summer and fall writing tests for some of these modules, hearing from some maintainers that I couldn't use core modules in those tests because those core modules hadn't been in core long enough that they were available on older versions of Perl long enough for people to have them installed, nevermind that if they were capable of installing newer versions of these modules, they were fully capable of installing dependencies, and suddenly I wonder if I've had a persistent pounding in the back of my skull since about June of 2001, because sometimes it sure feels that way.)
Several modules are in this situation, and we don't have good answers to several questions:
- Who maintains this code?
- Which version of this code is authoritative?
- Which release of this code should supersede other releases?
- When will the next release take place?
- What are the dependencies of this code?
- What is the support and deprecation policy for this code?
- What are the requirements for dependencies in language or supporting libraries for this code?
Good software developers and project managers ask and answer these questions regularly. Your answers are critical to the long-term success and maintainability of your project.
I'll talk about p5p's answers in my next entry.
(If you hate the pun in the title, trust me: all of the other candidates were worse.)
