This is probably obvious to anyone paying attention to my CPAN releases over the past few years, but in case it’s not, I wanted to state this clearly. All of my Perl modules are in maintenance mode.
Why? I no longer do any professional work with Perl, and I haven’t done any since 2017 or so. All of my most enjoyable personal projects are in Rust these days. Also, I’m a bit burned out on the Perl community. I think as it’s shrunk some of the most unpleasant aspects of it have been amplified for me, and my time on the Perl and Raku Foundation board exposed me to even more of this, further burning me out. Please note that I’m not talking about TPRF’s board or volunteers here!
So here’s what “maintenance mode” means to me …
I will not personally work on significant new features. The definition of “significant” here is nebulous, but basically, if it takes more then a few hours of effort, I’m probably not going to work on it.
I may review PRs for significant features, but honestly, I probably won’t have the motivation for this. If you want to propose a significant new feature that requires careful review, then the best way to get this to be merged would be to also find some reviewers to look at it. If someone submits a bigger PR and a few other people review it that I trust1, I’m a lot more likely to merge it.
I will not personally make releases that break backward compatibility for
most of my modules. I qualify this with “most” because there are some things
that aren’t widely used that I’m okay with breaking, for example, my personal
Dist::Zilla
bundle and other
things where I’m the main (or only) user.
I will probably not hand off ownership of widely used modules. Some of
my code is very widely used, including things like
DateTime and
Log-Dispatch. I’m very wary of
giving others control of these since breakage in one of them can break a lot
of CPAN or a lot of existing applications. I do welcome help with
maintenance in the form of PRs and PR reviews!
This includes modules like Specio, where
it’s in wide use entirely because it’s used in DateTime.
Given all this, if for example, you have a suggestion for a DateTime 2.0
feature, I think the best option is to fork DateTime (into a namespace not
starting with DateTime) and go ham on it.
I will try to keep my Perl modules working with newer Perl versions. So far this has generally not been too difficult. If that changes, I will reconsider my stance on handing over ownership.
I will try to fix bugs in code and land mines in APIs. I will do this as long as they can be fixed in a backward-compatible way, without major surgery on the code, in a reasonable amount of my time. Backwards compatibility trumps correctness here, especially if the buggy behavior is documented. This goes double for “bugs” of the form “I don’t like this documented” behavior. That’s not a bug, that’s a design decision you disagree with. See above about forking.
One safe way to fix land mines is to add new methods/functions/parameters,
like I’ve done with
Time::Local. PRs to do this sort
of thing are welcome and encouraged, with the caveat about significant
features from above.
How long will I continue to do this? I don’t know. I’m amazed that people are still using code I wrote over 20 years ago! Will they still be using it 20 years from now? Maybe. Will there be new versions of Perl to deal with then? Will I still want to touch any of this code? I have no clue.
I can’t list all the people I trust. But I’d say that a good reviewer is someone with a long history of using Perl who understands The River of CPAN metaphor. If you want to know if someone would be a good reviewer, you can email me to ask or find me on the TPRF Slack. ↩︎