develooper Front page | perl.perl5.porters | Postings from January 2012

Re: [perl #109408] Documentation that refers to Perl 5 as new

Thread Previous | Thread Next
From:
Brian Fraser
Date:
January 31, 2012 19:19
Subject:
Re: [perl #109408] Documentation that refers to Perl 5 as new
Message ID:
CA+nL+nbtzeAx6LO_3Fnd+i4kvGYwOsLg4bDs8GCrv0wuX=RNDw@mail.gmail.com
On Tue, Jan 31, 2012 at 1:03 PM, Nicholas Clark <nick@ccl4.org> wrote:

> On Tue, Jan 31, 2012 at 08:43:36AM -0700, Tom Christiansen wrote:
> > > The ticket's more general question remains, about the start of "new".
> >
> > I am somewhat leary about calling something "new" (as opposed to  "new to
> > 5.x"), because it's going to be dated soon enough no matter what you do.
> > Maybe one could use "recent" instead at times, but that still gets stale.
> >
> > It doesn't seem to make much sense to call things "new" that appeared in
> a
> > release that's no longer supported.
>
> Sorry, to be clear, I didn't mean to suggest using an unadorned "new".
> I still mean "new in v5.8" or "new in v5.12". But I meant that we should
> pick a release before which we don't feel the need to highlight features
> added in it at all. And in the future when we move the cutoff forward,
> trim the parts of the documentation that are no longer accurate in
> advertising something as new.
>
> I don't think that we should be using unadorned "new" at all, even "new in
> this release", as it will so easily date, and effectively represents a
> maintenance liability, because they have to be manually corrected in the
> near future.
>
> > I think I myself generally call "recent" the current or previous release,
> > and stop there.  That means 5.12 is recent and 5.10 isn't.  But not for
> long.
> > Maybe 3 years for recent?  Dunno.
> >
> > One problem is how vendors take decades to ship recent Perl, so that
> > changes the recent yardstick to people who just use whatever they
> > have shoved at them.  But that's not our fault, and I don't think
> > it helps anyone for us to try to cater to it.
>
> Agree on ages - 5.8.8 was release 6 years ago today, is still the
> /usr/bin/perl in at least 2 widely distributed commercially supported
> Linux distributions.
>
> It's subjective, but I disagree on the last part - I think it does help
> people using or upgrading from these common older versions if we mention in
> current documentation that features are newer. It acts somewhat as an
> advertisement in what you could have if you upgraded, and it stops anyone
> from being confused or frustrated if they are reading newer documentation
> but working on (or targeting portability back to) an earlier version.
>
> (Interestingly, my hunch on what is most common is already wrong - the 2010
> Perl Survey showed 5.10.x just ahead of 5.8.x:
>
>
> http://survey.perlfoundation.org/Data-PerlSurvey-2010/R/07_perl_info/index.html
>
> However, in 2010, all the firms that I was aware of Perl version were still
> on 5.8.5 or 5.8.8.
>
> Admittedly a small number, but the fact that none had even upgraded to
> 5.8.9, which should be trivial, suggested that there was uniformity in
> the lag on organisations whose main application runs on Perl.)
>
> Nicholas Clark
>


https://github.com/Hugmeir/utf8mess/tree/pod-109408

So.
I more or less went ahead and did this, to some extent. To some other
extent the changes are stylistic, like consistently using v5.x.y instead of
5.x or 5.x.y or whatnot in perlvar (and only in perlvar, so as to avoid
bikeshedding). I also bumped most odd versions, post 5.6, to the next
stable release (so, for example, 5.7.1 became 5.8.0, and 5.9.0 became
5.10.0, but 5.005 is still 5.005).

There's only one big deletion, which was most of perltrap.pod -- It dealt
with traps for Perl 4 programmers migrating to Perl 5. It would be really
swell if someone could update perltrap for their other favorite language of
choice, since right now the document is severely lacking, only dealing with
awk, shell, C/C++, and Perl itself.

There's some stuff that I didn't really know about, so I left it alone,
including all of perlhack(tips)? and perl(re|deb)?guts.
One thing that came up in IRC while I was doing this is that having a table
in perlvar detailing in which version each variable became available would
be really swell. And I know that brian d foy compiled one for string/regex
escapes, which strikes me like a good candidate to get in as well.

Also, there's this note on perlre:

As of 5.005, C<$&> is not so costly as the other two.


Anyone knows if this is still true?

As a bit of a warning to anyone following from home, I regen'd
known_pod_issues.dat, so don't fall for the lie of the passing podcheck.t:
perlsec and perltrap fail. I probably left an open =over somewhere, or
sosuch; Haven't really looked into it yet.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About