... getting geometrically shorter, is a crock.
Would you care to elaborate?
I don't remember seeing an official written support policy anywhere before 5.12.3 in 2011-Jan
Or for that matter a release schedule.
I like the new commitment from the community and I think two major versions, and 3 years of security fixes is enough official support -- with any backporting done by those who need it.
5.18.0 is projected for 2013-05-18, so the release schedule is fairly stable -- looks like a good idea to me and definitely not a crock.
For those who want to know see perlpolicy#MAINTENANCE AND SUPPORT
This document codifies the support and maintenance commitments that the Perl community should expect from Perl's developers:
- We "officially" support the two most recent stable release series.
5.12.x and earlier are now out of support.
As of the release of 5.18.0,
we will "officially" end support for Perl 5.14.x,
other than providing security updates as described below.
- To the best of our ability,
we will attempt to fix critical issues in the two most recent stable 5.x release series.
Fixes for the current release series take precedence over fixes for the previous release series.
- To the best of our ability,
we will provide "critical" security patches / releases for any major version of Perl whose 5.x.0 release was within the past three years.
We can only commit to providing these for the most recent .y release in any 5.x.y series.
- We will not provide security updates or bug fixes for development releases of Perl.
- We encourage vendors to ship the most recent supported release of Perl at the time of their code freeze.
- As a vendor,
you may have a requirement to backport security fixes beyond our 3 year support commitment.
We can provide limited support and advice to you as you do so and,
where possible will try to apply those patches to the relevant -maint branches in git,
though we may or may not choose to make numbered releases or "official" patches available.
Contact us at <perl5-security-report@perl.org> to begin that process.
See also http://search.cpan.org/dist/perl-5.17.1/Porting/release_schedule.pod, perlhist
| [reply] |
Assuming this was intended as a reply to my post rather than bulk88's.
With 5 months between major versions, that equates to a whole 10 (TEN) months before all a vendors efforts to ensure the distributed version of perl works with all the distributed packages and tools it supplies written in perl are obsolete. It isn't long enough.
It is no wonder that vendors (redhat et al) are choosing to stick with old versions. With Perl's major version changing twice (or 3 times) between vendors major releases, by the time they've frozen their distribution and taken it through their testing processes to a release, the Perl they included is not just out-of-date, it is out-of-official-support.
With the recent rates of turnover, there is never a period of stability long enough for them to get from code-freeze to release. And if they've got to stick with an out-of-support version, why wouldn't they stick with the one they know.
Or more likely, drop their dependency upon the unstable moving target that is Perl, throw in an old version as a token gesture, and move over to using Python.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
| [reply] |
| [reply] |
RedHat also stuck with their own custom-crippled version of Perl for 2 years. That's long enough. It feels like you are implying a piety and competence in the vendors and an insanity in the Perl side that is not supported by the facts.
Though I personally don't expect the OS vendor to build or support the Perl I want to use for development at all. They can have whatever they want and we can have whatever we want; if lucky enough to work in that kind of shop. No one has to be a loser or a bad guy.
| [reply] |
