> On Aug 5, 2016, at 12:01 PM, Zefram <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. -- Andy Lester => www.petdance.comThread Previous | Thread Next