proposed changes for perlpolicy updates

see http://nntp.perl.org/group/perl.perl5.porters/219866

diff --git a/pod/perlpolicy.pod b/pod/perlpolicy.pod
index c6e0bbd..6efa082 100644 (file)
--- a/pod/perlpolicy.pod
+++ b/pod/perlpolicy.pod
@@ -155,23 +155,19 @@ We want to ensure that Perl continues to grow and flourish in the coming
 years and decades, but not at the expense of our user community.
 
 Existing syntax and semantics should only be marked for destruction in
-very limited circumstances.  If a given language feature's continued
-inclusion in the language will cause significant harm to the language
-or prevent us from making needed changes to the runtime, then it may
-be considered for deprecation.
-
-Any language change which breaks backward-compatibility should be able to
-be enabled or disabled lexically.  Unless code at a given scope declares
-that it wants the new behavior, that new behavior should be disabled.
-Which backward-incompatible changes are controlled implicitly by a
-'use v5.x.y' is a decision which should be made by the pumpking in
-consultation with the community.
-
-When a backward-incompatible change can't be toggled lexically, the decision
-to change the language must be considered very, very carefully.  If it's
-possible to move the old syntax or semantics out of the core language
-and into XS-land, that XS module should be enabled by default unless
-the user declares that they want a newer revision of Perl.
+very limited circumstances.  If they can be easily replaced, are
+believed to be very rarely used, and stand in the way of actual
+improvement to the Perl language or perl interpreter, they may be
+considered for removal.  If both the cost and the gain are believed to
+be low, backward compatibility wins.  When a feature is deprecated, a
+statement of reasoning describing the decision process will be posted,
+and a link to it will be provided in the relevant perldelta documents.
+
+Using a lexical pragma to enable or disable legacy behavior should be
+considered when appropriate, and in the absence of any pragma legacy
+behavior should be enabled.  Which backward-incompatible changes are
+controlled implicitly by a 'use v5.x.y' is a decision which should be
+made by the pumpking in consultation with the community.
 
 Historically, we've held ourselves to a far higher standard than
 backward-compatibility -- bugward-compatibility.  Any accident of