NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Deprecations should not break software. (Score:2)
Since we don't have a decent API versioning scheme, it often feels like the right thing to do is to change the namespace when you're making a change that will nontrivially break backcompat.
Amongst my other complaints:
Deprecation does not equal deletion.
Re: (Score:1)
As Matt pointed out though, nobody reads the documentation.
Further, please let me be clear to everyone that Module::Install is NOT like other parts of the toolchain.
If I remove auto_install from Module::Install, it DOESN'T impact end users (the people installing modules) at all.
Existing modules with auto_install in them will continue to work exactly the same and don't break. This was the entire principle behind Module::Install in the
Re:Deprecations should not break software. (Score:2)
As of 0.68, auto_install is part of the _recommended_ usage in my copy of Module/Install.pod
You say: "If I remove auto_install from Module::Install, it DOESN'T impact end users (the people installing modules) at all."
That's true for people installing from CPAN, but it's plenty common for people to check things out of subversion repositories or otherwise end up with a Makefile.PL that uses Module::Install and end up regenerating inc, but yes, I acknowledge that this isn't as bad as if someone gratuitously broke backwards compatibility in MakeMaker.
But yeah, call it "the feature has been removed" when that's what you mean. Deprecated means "this will be changed or removed in the future, it's time to start migrating away" not "this is already gone"
Reply to This
Parent