Front page | perl.perl5.porters |
Postings from May 2012
[perl #112792] Perl Major Release Doc Flaws (5.8.0->5.10.0)
Thread Next
From:
Linda Walsh
Date:
May 6, 2012 12:35
Subject:
[perl #112792] Perl Major Release Doc Flaws (5.8.0->5.10.0)
Message ID:
rt-3.6.HEAD-4610-1336332914-1731.112792-75-0@perl.org
# New Ticket Created by Linda Walsh
# Please include the string: [perl #112792]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112792 >
This is a bug report for perl from perl-diddler@tlinx.org,
generated with the help of perlbug 1.39 running under perl 5.14.2.
-----------------------------------------------------------------
[Please describe your issue here]
If someone has not upgraded through each point release of perl --
a perfectly reasonable expectation under older releases where
point releases can out often, to address what was supposed to be
minor details while keeping compatibility within the major
5.X series (with interface changes going into larger 'point' releases,
like 5.8->5.10 5.10->5.12 -- but then only with "use newfeature"),
This practice was not (and often, is not) adhered to resulting in
chaos and a rain of crap upon users.
In 5.8.0, full UTF8 support on I/O was introduced:
Previously in Perl 5.6 to use Unicode one would say "use utf8" and then
the operations (like string concatenation) were Unicode-aware in that
lexical scope.
This was found to be an inconvenient interface, and in Perl 5.8 the
Unicode model has completely changed: now the "Unicodeness" is bound to
the data itself, and for most of the time "use utf8" is not needed at
all. The only remaining use of "use utf8" is when the Perl script
itself has been written in the UTF-8 encoding of Unicode. (UTF-8 has
not been made the default since there are many Perl scripts out there
that are using various national eight-bit character sets, which would
be illegal in UTF-8.)
There has been no mention of a change in any major release since
then.
The fact that it is NOT this way in 5.10, .12, .14 (likely .16), ..
is a complete failure in the release process in documenting major changes from release to release.
Only if one is involved in the day-to-day internal politics and development of perl and keeps track with every 'minor bug fix release' (of the sort that isn't to break compatibilty) or make incompatible interface changes, might one have seen in some footnote or other that this was no longer the case.
Apparently, someone slipped in a major UI change into a "minor release", and got it through approvals -- something that should never have happened.
But maybe it was somehow consider an 'emergency so dire that normal release processes had to be ignored'.
But if that was the case, one would have expected to see some note, or mention of this major change when 5.10.0 came out -- with major UI changes since
last main release.
This was not the case. I couldn't figure out why so many progs broke that were re-written to take advantage of the specification of 5.8.0.
I may have updated at 5.8.4 or 5.8.6 -- But usually when my distros upgrade
it's to 5.MAJ.<X for some X>0. I many do minor release upgrades by pulling down my own perl between distro releases, especially when I see a feature like full UTF-8 support based on ENV/local, because it was the direction of the future and as furter proof of that opinion, is now the HTML5 standard.
So I can easily see my jumping at the new support -- and finding it great! -- but then not seeing some footnote, that a Major incompatibility was introduced in 5.8.1. This major step forward was quietly removed.
No mention in the next 5.10.X version my distro released...(there might have
been a 5.8.9 in there with no mention of the issue or to read previous docs --I think 5.8 was during the 'slowdown' time).
Even more ironic is that 5.10.0 talks about more functions being converted to UTF-88 (Win32::GetLongPathName), rather than latin1 so instead of a mention of perl's backstep, we see what looks like progress. From then on, I see only mention of increasing compatbility... *BLECH*.
Slipping these types of changes in without notes in major releases seems completely vacuous at best, if not irresponsible. Too often changes are being made in the perl package by "perl-community insiders", who have no realistic view of how their changes are seen or will affect those who are not day-to-day members of the perl community, or users who use perl without being "of perl"...
>From my point of view, 5.10, 5.12, and 5.14 are all broken as no mention was
made of the change intro'ed to 5.8. That's the source of some of my recent confusion (and a whole subclass of unicode bugs caused by this incompatible change.
Someone may have thought they were getting pleasing their 'core friends' by reverting that functionality, but others were relying on it and who didn't get the dday-to-day sub-release messages, that sound like a posix or w3c committee yanking a standard around from meeting to meeting. Justing by the living Html5 website, I get that this practice isn't very well received by people trying to actually use released versions.
>From my perspective, I'll have to make sure the env var PERLIO is set, and either fail if not, or set it to the default as specified in the in the last major release to mention a change in this area.
That will ensure compatibility by default with major releases, putting the onus of change on those who slipped in major UI changes in a minor release, to invoke a 'change method' (set the ENV var, whatever), as it should have been in the first place.
It's not that I even agree or disagree with the engineering reasons that went into the decision -- but the way the process was done was (and still is) decidedly broken.
If perl wants to move forward, the whole community needs to be more responsible about intro'ing changes in major releases, with deprecation announcements and compatibility options if at all possible (there may be some that are impossible, I dunno, but this wasn't one of them).
This is a severe bug in the way *releases are handled*, -- i.e. I'm not so dillusional to think that anyone would follow the major specifications as described in the major releases' release notes.
The release note process ("What's New") **SHOULD** be vetted for missing references to major UI changes that were slipped in during "minor releases" so no one else will find these changes "suprising" years later.
I may be the only one on this list that this is news to, but I doubt I'm the only perl user in the world who has missed 'inconsequential, minor'[sic] changes like this.
This may only be a call for changing the process forward to either roll all **major changes** into the next V's what's new (non-minor changes that were done
in 'minor' releases, that wouldn't have been seen for those looking through major release notes to see what major changes have been wrought.
Yeah, this may look like a rant. But if you think what I'm saying has no merit, you are part of the problem that is killing perl.
[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
category=core
severity=high
---
This perlbug was built using Perl 5.14.2 - Sat Oct 29 15:59:10 UTC 2011
It is being executed now by Perl 5.14.2 - Sat Oct 29 15:55:30 UTC 2011.
Site configuration information for perl 5.14.2:
Configured by abuild at Sat Oct 29 15:55:30 UTC 2011.
Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
Platform:
osname=linux, osvers=3.1.0-rc10-1-default, archname=x86_64-linux-thread-multi
uname='linux build33 3.1.0-rc10-1-default #1 smp thu oct 20 08:17:26 utc 2011 (f6d77d4) x86_64 x86_64 x86_64 gnulinux '
config_args='-ds -e -Dprefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true -Doptimize=-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe -Accflags=-DPERL_USE_SAFE_PUTENV -Dotherlibdirs=/usr/lib/perl5/site_perl'
hint=recommended, useposix=true, d_sigaction=define
useithreads=define, usemultiplicity=define
useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
use64bitint=define, use64bitall=define, uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
optimize='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -pipe',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector'
ccversion='', gccversion='4.6.2', gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib64 -fstack-protector'
libpth=/lib64 /usr/lib64 /usr/local/lib64
libs=-lm -ldl -lcrypt -lpthread
perllibs=-lm -ldl -lcrypt -lpthread
libc=/lib64/libc-2.14.1.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.14.1'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl5/5.14.2/x86_64-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib64 -fstack-protector'
Locally applied patches:
---
@INC for perl 5.14.2:
/usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.14.2
/usr/lib/perl5/vendor_perl/5.14.2/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.14.2
/usr/lib/perl5/5.14.2/x86_64-linux-thread-multi
/usr/lib/perl5/5.14.2
/usr/lib/perl5/site_perl/5.14.2/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.14.2
/usr/lib/perl5/site_perl
.
---
Environment for perl 5.14.2:
HOME=/home/law
LANG=en_US.UTF-8
LANGUAGE (unset)
LC_COLLATE=C
LC_CTYPE=en_US.UTF-8
LD_LIBRARY_PATH (unset)
LOGDIR (unset)
PATH=.:/sbin:/usr/local/sbin:/opt/lsb/bin:/home/law/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/lib/qt3/bin:/usr/sbin:/etc/local/func_lib:/home/law/lib:/home/law/bin/lib
PERL_BADLANG (unset)
SHELL=/bin/bash
Thread Next
-
[perl #112792] Perl Major Release Doc Flaws (5.8.0->5.10.0)
by Linda Walsh