Re^3: What is a really old version of Perl? (Instability == death knell)

[BrowserUk]

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.

[moritz]

I don't know where you've got your numbers from, but major releases are every 12 months, not 5. That's both the plan and how it worked out since the beginning of the time-based release schedule.

[BrowserUk]

but major releases are every 12 months, not 5.

I guess that depends upon whether you consider the x.x.0 release of anything a viable candidate for serious use. Many do not.

[Tux]

FUD. One of the reasons why OpenSUSE doesn't do .0 releases anymore. 12.1 is current, there has never been a 12.0

[Your Mother]

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.

[BrowserUk]

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.

I'm not implying anything, just drawing attention to what is writ large all around.

Platforms -- whether vendor or in-house -- move slowly. Whilst Linux distributions may allow individuals to co-install later versions of third-party packages, in-house platforms rarely do.

A family member -- a UK civil servant -- has just taken delivery of her hot-desk/home working laptop. I helped guide her connecting it to her home wifi. She had trouble establishing the VPN connection, which turned out to be a switch on the machine in the wrong position. But whilst trying to guide her through investigating the problem, it rapidly became clear that the machine and OS is so locked down that it was impossible to do *anything*. No command line; no accessible local drives; no unsigned usb devices; nothing but what was installed and encrypted by the platform developers. It will not change for 3 years.

A few years ago, I helped define and set-up the platform delivery and maintenance network for the 13 government departments that run an entire European country. It was more flexible than the UK setup, but it still required ministerial level sign-off to add 'extras' for particular sub-departments and individuals. And that required at least 6 months of trial before approval. The initial platform rolled out lasted 5 years before it got any substantial upgrade

The 6 year wait for defined-or was far too long, but it's my opinion that this has now swung too far the other way

I have no expectation of my opinion having any influence on those that make such decisions. But maybe some real-life examples and the opinions of someone like Matt Asay might.