On Wed, 20 Nov 2002, Nicholas Clark wrote:
[such as house policy on not using .0 versions? time taken to assess and
approve releases meaning that approving 5.8.0 is a lot of effort?
Something specific they don't like about 5.8.0?]
Basically is there something that the perl development community needs to do
(or change) that would avoid this in future?
I'm not Cisco, or the original guy, but here are the reasons I (and as the
Admin/Lead Programmer here my position is basically my company's position
on this) won't use Perl 5.8.0 for production servers:
1) x.0 release. I haven't seen a x.0 release of _any_ software I was
willing to put the family jewels on without quite a bit of testing
first.
2) The very first machine I installed it on immediately had script
breakage _specifically_ because the rather broken (IMHO) behavior
re making the use of either 'use bytes' or 'binmode' mandatory
if you want to get the same filehandle behavior semantics on *nix
boxes that Perl (and virtually all other *nix programs) have had
historically. I don't relish the prospect of identifying essentially
every use of 'open' in every program we have ever written just to
add 'binmode' or 'use bytes' to them to proof them against 5.8.0
originated dain bramage. When I open a file handle and read a file
I expect (by default) to get _exactly_ what is in the file. If I
want Unicode semantics, I'll explicitly specify them myself
"thenkyouverramuch".
Unicode is great - I am a huge believer it - but don't
go mucking up *nix semantics by making 'text mode' filehandles the
default: It _breaks_ things that were running 100% clean under
warnings and strict for years. I've distrusted the trend in Perl for
the last few years to 'magically' try to muck with charset encodings;
5.8.0 has specifically realized those fears as quite justified.
--
Benjamin Franz
I should either have been less specific or more correct ...
---Andy Armstrong <andy(_at_)wonderworks(_dot_)co(_dot_)uk>
