During a weekend discussion on the Perl 5 Porters mailing list, I volunteered to write a specification for Perl 5's support policy.
I believe in being explicit (darn it!) about what a community is willing to support and what community members can provide to other community members and users. I tried to reflect that when I wrote the first drafts of Parrot's support policy.
My goals are simple. I want to remove all magic and magical thinking from the release process. I want to remove all potential ambiguity from the upgrading process. I want to manage expectations so that the only surprise in a new release of the software is how well it delights users, and not that features have changed since the previous release.
That's easier with Parrot than with Perl 5, for several reasons:
- Parrot is new software, with very few users who aren't already part of the vocal Parrot community.
- Parrot has a regular release schedule which we can predict years in advance.
- Parrot's main users are compiler writers and distribution packagers. Both groups are familar with and capable of managing change, if we communicate it effectively.
- I have seniority on the project. (Don't underestimate that, if you want to influence a community.)
My goals for the Perl 5 support policy are to document current practices, to identify rough community consensus for future policies, and to encourage those policies toward modernization and sustainability. Boring, right? Perhaps it is, until you consider several constraints:
- Perl 5 releases are unpredictable in date and scope.
- There's no formal deprecation strategy.
- Perl 5's target users are developers, but not necessarily professional programmers.
- The maintainers of dual-lived modules have tremendous leeway as to updates and upgrades and compatibility changes.
- I don't have commit access to the project.
I admit my motivations: I want to encourage p5p to drop support for old versions and I want to see new major versions of Perl 5 released every year. I want a one year deprecation cycle (any feature announced as deprecated in a major release may be removed by the next major release). I want support dropped for releases two years old and older (barring a major security fix someone feels strongly enough to patch).
Mostly I want Perl 5 in 2010 to be better than Perl 5 in 2009, and so on, and so forth, without always worrying about how Perl 5 did things in 1999 and 2000.
That's what I want. Those are my goals and biases. What do you want?