<div>If the motivation is only this, IMHO it's a difficult approach to backward compatibility - you go online and find all usages, create pull requests, try to contact developers to have the fixes merged. If you don't find all usages (somebody's application not published online), then it will break after the change.</div><div> </div><div>If there is no difficulty keeping the old functions in the code base, I would leave them forever (for course deprecated).</div><div> </div><div>Just my opinion.</div><div> </div><div>18.09.2017, 00:52, "Faré" <fahree@gmail.com>:</div><blockquote type="cite"><p>On Fri, Jun 2, 2017 at 2:14 AM, Anton Vodonosov <<a href="mailto:avodonosov@yandex.ru">avodonosov@yandex.ru</a>> wrote:</p><blockquote> I mean is it impossible to keep existing forever (implemented in terms of the new, better API)?<br /> </blockquote><p>Some functions have a horrible API that is error-prone or misdefined<br />and should NOT be used by anyone when better APIs are available.<br />RUN-SHELL-COMMAND is a case in point — that horrible function must<br />die, it's a security nightmare as well as a usability absurdity.<br /><br />SYSTEM-DEFINITION-PATHNAME was historically doing the wrong thing; we<br />provide an approximation of what it used to do in terms of supported<br />interfaces, but the only way to be sure that the user doesn't mean<br />something crazy in terms of the old meaning is to migrate to the new<br />interfaces.<br /><br />—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• <a href="http://fare.tunes.org/">http://fare.tunes.org</a><br />Good girls are bad girls that never get caught.</p></blockquote>