develooper Front page | perl.perl5.porters | Postings from June 2015

Half a deprecation cycle? [was: deprecate POSIX::tmpnam]

Thread Previous
Aristotle Pagaltzis
June 29, 2015 07:36
Half a deprecation cycle? [was: deprecate POSIX::tmpnam]
Message ID:
* Ricardo SIGNES via RT <> [2015-06-28 01:25]:
> If we drop the code without two years of deprecation, some upgraders
> will have their library fail to compile (or run) without warning ahead
> of time.
> Then again, to what extent is the code really "working" now?  My
> sentiment is "maybe well enough," but it's a lousy sentiment and I'm
> not really married to it. Anybody else want to throw an argument on
> the fire?

If the code is already so broken that we’re willing to drop the second
half of the deprecation cycle and let a significant subset of users
crash with no warning, then what makes it imperative to warn the other
subset of the users through a half deprecation cycle?

Note that this is neither meant as proof by contradiction nor a foregone
conclusion. I have no problem admitting the idea of skipping deprecation
entirely. But I don’t know that we should, either.

However, if the logic applies to some users purely based on timing then
surely it may apply to all of them.

But more importantly, also conversely: if that suggestion seems clearly
like a bridge too far – if a deprecation warning definitely MUST be
granted to SOME subset of users – then maybe the logic applies to none.

So if we decide on an abridged deprecation cycle, we should come out of
that with some criterion or at least indication for when no deprecation
would be bad but a full two-release deprecation would also be bad.

It seems like a self-contradictory position.

That doesn’t mean the contradiction cannot be resolved of course: there
just has to be some factor that unravels the knot.

Do we see anything like that?

(I don’t know enough about the issue itself to have an opinion.)

Aristotle Pagaltzis // <>

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