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

How we deprecate (was Re: Deprecating '\w {' in v5.16)

Thread Next
David Golden
January 29, 2012 18:21
How we deprecate (was Re: Deprecating '\w {' in v5.16)
Message ID:
On Sun, Jan 29, 2012 at 3:50 PM, Father Chrysostomos <> wrote:
> My reasoning is this:  We are too close to 5.16.  Some of my seemingly innocuous bug fixes are causing all sorts of CPAN test failures.  Adding a new deprecation at this stage that is certain to cause breakage (due to warnings tests) or obnoxious nagging is unwise.  I would suggest we do it early in the 5.17 series, if we are going to do it at all.

With due respect to Father Chrysostomos' concerns about test failures,
I have a different point of view about deprecations in the development

I expect that 99.9%+ of Perl users do not build dev releases (much
less test code on them), as much as we encourage them to.  Thus, I
don't expect anyone to react to a deprecation warning until the stable
release in which deprecation warnings start.  (Thankfully, we have
Andreas who regularly smokes blead because that's most of the "live
code" smoking we get.)

So while I don't like "risky" code late in the dev cycle (by which I
mean things that are complex and might have surprising bugs revealed
in testing), I don't see any reason why deprecations can't be
introduced right up to the code freeze, since the only point it really
affects most users is when the stable release is done.

However, we should think about how we want to deprecate things: do we
want a deprecation warning (or many of them) to follow simultaneously
with the announcement of deprecation in a stable release?

Jesse's vision included the notion that changes should happen
lexically under in a declared version block, whenever possible.  So in
this case, perhaps the deprecation warning should only occur under
"use v5.16"?  Frankly, I think the lexical version declarations are
going to be horribly confusing and I question whether that's the right
path forward or whether a simpler policy change would be more

Right now, perlpolicy defines "deprecated" and says that deprecated
features will warn.  I wonder if it would be better to introduce a new
category, "scheduled for deprecation", which would be public notice of
future deprecation for one stable release cycle, after which the
feature would be "deprecated" (and begin warning), after which the
feature would be "removed".  This three-stage removal process would
give an extra period of notice before code behavior changes.  (I still
expect few to pay attention until code warns, but at least we'd be
able to tell them they had notice*.)

[Irrespective of such a policy change, I think the lexical version
declaration could potentially still be used in certain circumstances
("when possible") to extend the period in which a deprecated feature
is still available and not warning, though I question that approach as
stated before.]

-- David

* And better notice than putting it on display in the bottom of a
locked filing cabinet stuck in a disused lavatory with a sign on the
door saying "Beware of the Leopard".

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About