...and I'd like a pony... and I'd like to have that fact mean I'll be getting one soon.
But that ain't the way the real world works... nor is specifying a version always based on any real-world reality.
Do you have any method for demonstrating 'truthfulness' in your statement (below) that you "can't ask them (users) to upgrade" from an obsolete version? If you're providing the programming expertise, you clearly have standing to -- at a minimum -- suggest they install a version that has overcome certain known bugs or added abilities. They don't have to delete 5.8 which, likely, is used for system functions; you'll find many threads here about how to ADD a current Perl version to a system without borking the system-Perl.
BTW and FWIW, the fact that RH says it will support 5.8 until 2017 for RHEL5 does NOT mean RH will cure the bugs (nor the shortcomings) of 5.8 compared to 5.10, 5.12, etc.
Sometime, it takes a 'clue by four' to get a mule to do the right thing.
| [reply] |
Do you have any method for demonstrating 'truthfulness' in your statement (below) that you "can't ask them (users) to upgrade" from an obsolete version?
See OP. Most of those who runs linux have outdated version of Python, Ruby and Perl. And they used to use Perl, Ruby and Python software without upgrading all their stuff.
BTW and FWIW, the fact that RH says it will support 5.8 until 2017 for RHEL5 does NOT mean RH will cure the bugs
Yes, only security fixes are guaranteed. And they sometimes backport bugfixes.
| [reply] |
See OP. Most of those who runs linux have outdated version of Python, Ruby and Perl. And they used to use Perl, Ruby and Python software without upgrading all their stuff.
As does every version of MacOS X. Many versions of MacOS come with two Perls, at least one of which is used by many system functions, is known to be outdated, and some of those system functions depend on the bugs of the outdated version, which is why you shouldn't muck with it.
All of that is why it's recommended that you install your own Perl (or even multiple versions of your own Perl) so that a) you don't bork the system Perl by updating some module or other, and b) don't have your programs borked when the system decides to overwrite versions that you're depending on when you do a system version upgrade. The same applies for Ruby and Python. I work mostly in Perl and Ruby, and I have my own installs of both on my dev machines and on the production servers.
So recommending an upgrade that fixes a some bugs or adds some features shouldn't be that big of a deal. And I find that Perl is much more robust during upgrades than Ruby-- I can usually move to a later version of Perl and have bugs be fixed without breaking working code. Ruby, not so much.
| [reply] |
para 2 (ie, your "See OP. Most of those ...." is irrelevant to the discussion and does NOT answer the question.
and "they sometimes backport bugfixes." So?
I guess "sometimes" is the operative word (AKA 'polecat in the wood pile') and it undermines many of your prior arguments.
Above is my last comment in this thread: I'm down to debating the number of angels who can dance on the head of a pin... and the point-counterpoint is beyond ridiculous already.
but, update: fixed missing close-quote. clarified question by adding "So"
| [reply] |