Yesterday, after a little over a 1 year wait between productions, I (finally) uploaded the final release of PPI 1.200.
This is the second time I've made the mistake of trying to get too ambitious with a major release, at the risk of never releasing.
I knew the features I wanted, but I had no idea when I'd have the time to actually write them, and I felt that I couldn't release until they were done.
But my desire to avoid releasing also had the problem that general fixes and parsing regressions/bugs weren't going into prod, they were going into 1.200.
So my tardiness with the new features was also damaging the production release, and in the process hurting projects like Perl::Critic who had contributed those fixes (or the failing regression tests) and weren't getting anything back for their contribution.
Although, as chromatic has pointed out, that Free Software can take a long time to release, as far as I'm concerned this is a wrong approach for cases where one single author is blocking development.
There needs to be a line at which the slow pace becomes not a programming issue, but a management issue, and for me this line is 1 year.
If you (or I) have exclusive control of an Open Source project, and someone brings a fault/bug (and ideally a fix) to the attention of the maintainer, and this fault is not addressed for a year or longer, I consider the maintainer to be guilty of project mismanagement.
They need to either get the bug fixed, hand off the module to a new maintainer, give commit rights to the person that wants the bug fixed, or otherwise just get the hell out of the way and stop being a problem.
Of course, chromatic's original case of Perl 6 doesn't apply, because the Perl 6 people are quite happy for you to join up and work on Perl 6.
I gave about a year notice to ActiveState on the PPM build farm problems, to Andy regarding Template Toolkit's terrible treatment of Win32, and to Test::Reporter on the SMTP problems.
All three had people that weren't fixing problems, but weren't allowing others to fix them either.
And I think in all three cases, moving to a more aggressive posture (creating a better Perl Distribution in Strawberry Perl, briefly taking over Template Toolkit, and publicly and harshly reviewing Test::Reporter) has had very positive results.
If I'd done it immediately, things would be less good. I made a terrible mistake in the early days of getting my CPAN admin bit when I forcefully took over Email::Send, and I've regretted it ever since.
People deserve a chance to fix their problems. But for me, if you can't fix your problems in a year you need to either start being the solution or get the hell out of the way.
And so PPI 1.200 is not everything I originally wanted it to be.
It was simply time for me to get a stable release out there, no matter what, because I was starting to be the problem and not the solution.
Most of the features and much of the regression work in PPI 1.200 are the work of amazing Chris Dolan. He deserves far more credit for PPI 1.200 than I do.
The biggest user-visible change is the complete refactoring of the PPI::Token::Number tree, which not contains separate sub-classes for each of the numeric types.
These also contain the beginning of the ->literal method implementation, which lets you (safely) get the actual Perl value for various tokens or trees.
I had wanted a fuller implementation allowing the literal'ing of nested ARRAY references and so on, but I simply didn't have time to implement it.
Internally, the biggest change is to move to exceptions for error handling inside the tokenizer and lexer. This removed a TON of cases like
$self->foo or return undef;In the process, simplifying these cases also allowed a number of methods to be inlined and all the extra inlining plus the removal of all those conditionals should result in a slightly faster tokenizer (before the addition of any extra code to handle regressions).
