Front page | perl.perl5.porters |
Postings from September 2016
Re: RFC: perldeprecated.pod
From: Aristotle Pagaltzis
September 23, 2016 20:58
Re: RFC: perldeprecated.pod
Message ID: 20160923205827.GA69185@plasmasturm.org
* Kent Fredric <email@example.com> [2016-09-22 20:48]:
> On 22 September 2016 at 21:21, Abigail <firstname.lastname@example.org> wrote:
> > when the deprecated ones are scheduled to be
> >> removed, or that there is no current plan to remove them.
> > I think we should eliminate the latter category.
> Disagree. That category mostly exists because we shouldn't be removing
> things "just because".
I agree with the justification but not the conclusion. We can and should
still eliminate that category. I continue to advocate that we scale down
all long-standing still-indefinite deprecations to discouragements. That
is effectively how they were intended anyway; that distinction only came
about long after many of them were deprecated.
People don’t like the suggestion because per a legalistic interpretation
of the policy, already-deprecated features could be removed without an
extra deprecation cycle – at least in theory – whereas scaling them back
to discouragements would require an extra deprecation cycle if they ever
were to be removed.
Then, inevitably, the discussion fizzles out, and nobody even reviews
any of the deprecations, so they just continue to stick around as long-
standing indefinite deprecations for years down the line. So the bottom
line in practice is that p5p retains liberty to remove them quickly at
some hypothetical point in the future, at the cost of clarity for users
in the meantime.
Clarity for users, of course, is the whole point of having a policy. If
it’s just there for the benefit of developers seeking to feel justified
in their actions, without helping users evaluate their situation, then
it’s just window dressing.
I would like it to not be window dressing.
My line of argument is further reinforced by the fact that if we were to
actually try to remove long-standing indefinitely deprecated features,
many of them will probably cause too much breakage to actually remove on
the theoretically/legalistically possible accelerated schedule. So these
will effectively end up running on the same schedule as if they had been
scaled back to discouragements. Then the only difference is in how clear
their status is to users in the meantime.
And a final flank is that if we are serious about the policy as laid out
in the document – which is not to remove things before they actively get
in the way – then a push to carefully review the status of long-standing
indefinite deprecations will merely end up scaling most of them back to
So we should do users a favour and just go with that.
Aristotle Pagaltzis // <http://plasmasturm.org/>