Front page | perl.perl5.porters |
Postings from August 2016
On 08/05/2016 07:15 PM, Andy Lester wrote:
>
>> On Aug 5, 2016, at 12:01 PM, Zefram <zefram@fysh.org
>> <mailto:zefram@fysh.org>> wrote:
>>
>>> feature.pod already contains all the features
>>
>> Deprecated features are not necessarily (or even usually) switchable
>> features governed by the feature.pm pragma.
>
> I think there’s value in specifically calling out deprecations in a
> separate document.
>
> Also might be good to have something in there about how to check your
> code for a given deprecation. If I’m looking at a piece of code
> running under 5.8 and I’m wondering if I can run it under a more
> modern version, how can I tell by examining the code if it’s using,
> for example, pseudohashes? grepping for “use deprecated_module” is
> easy enough, but for others it’s not.
>
> And maybe this document isn’t about just deprecations. Maybe it’s
> about upgrading in general. I went through an upgrade from 5.10 to
> 5.20 a few months ago, and there was a lot of scanning of
> perldelta*.pod picking out “Will this affect us? Will this?" A
> high-level doc that is a summary of the deltas with an emphasis on,
> say, “HEY WATCH OUT FOR HASH RANDOMIZATIONS!” would be handy.
A big benefit in Karl's suggestion is that we could note down when we
intend to deprecate something or remove it in the future, in Karl's words:
This would help us remember to actually do the removals, and be
transparent to our customers.
That deviates from your proposal of documenting the past, which is what
we've done with perldelta. Perhaps we could create a document which
takes from all perldelta docs to form a bigger document relating only to
deprecated and removed features across different perl versions.
Thread Previous
|
Thread Next