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?
I think it's a significant strength of Perl that the scripts I wrote in 1999 are still running with no modifications and no extra thought on my part.
I think it's a significant weakness of C++ that programs I wrote last year don't compile with the latest compiler.
From a user point of view, I hate deprecation. Stop breaking my program! :-) From an API designer point of view, I hate backwards compatibility (it requires so much thought and testing). But in the end I think the users trump the designers.
There's almost always a way to add new functionality without breaking the old, but it's doesn't always end up being as clean, and I can understand resistance to ugliness. Though I suppose surely there is a happy medium there somewhere.
I guess that's not really a clear answer...
I think all of your "wants" are great. I think the single best thing is the yearly release cycle. Perception goes a long way.
I agree with sigzero about yearly releases. I don't necessarily think that having a fixed date for the release years in advance will help perception, but if that's the easiest way to have yearly continual advances in the version number then I'm all for that.
And as far as porkrind's comments go for his 1999 scripts, I think it's fine if newer versions of Perl break backcompat as long as the error messages are clear and meaningful and give good suggestions for the new replacement syntax. Having such great backcompat is nice until you see that most other languages don't do it and they get to evolve. Until we can specify the maximum version of Perl that our code works with then I think deprecation is the next best thing.
Flash accomplishes backward compatibility by shipping *the entire VM* for the old version along with the new version. They've evolved a couple of times, (Actionscript 3 has some signficant departures from previous releases) but Flash content from a decade ago still runs perfectly.
Perl could do that too: libperl.so v5.12.0 could bundle libperl.so v5.10.x and invoke that older version if legacy programs could specify (or trigger) a maximum/compatibility version.
That could be the best of both worlds (except for the developer who has to figure out how to do that bundling)
"I want support dropped for releases two years old and older (barring a major security fix someone feels strongly enough to patch)."
Long term backward compatibility is one of the things that keeps me writing Perl. Still, a "formal deprecation strategy" would be nice, and more so if it would also be enforced or at least available as a guideline to package maintainers on CPAN, so one module author would not break compatibility between version 5.80013 and version 5.80021, for example.
Supporting a release family (such as 5.8.x) and providing compatibility with a release are different. If 5.12 is out, what's the point in releasing 5.8.10? I can understand a 5.10.2 if there's a security flaw in 5.10.x, and perhaps a 5.8.10, but I don't understand working on new versions of older release families.
With that said, the current yearly release plan seems very effective. I have high hopes that it'll continue to work.