RE: Obsoleting more progressively

[Drew Adams]

SM> `make-obsolete' and friends are very useful to let us get rid of old
SM> features, but even after 10 years of something being declared 
SM> obsolete, experience shows it's still in use "out there".

Don't worry about it "out there".  Worry about it only "in here".  Worry only
about the code that you produce: the vanilla Emacs sources.

There are sometimes good reasons why code "out there" can continue to reference
constructs that have been declared obsolete.  Code that needs to work with
multiple Emacs releases can contain such constructs and can even sometimes
access some of them during runtime, sometimes even in a version where the
construct is obsolete.

That's at least possible, given the dynamic nature of Lisp code (including code
generation).  And it's not necessarily a problem if it happens.

And code "out there" can also contain constructs that happen to have the same
names etc. as vanilla constructs that have been declared obsolete.  There is no
way to automatically analyze code (static or running) to determine whether
something is actually an obsolete construct and, if so, whether its use is
actually problematic.

Even when there are _no_ good reasons for particular code "out there" to use an
obsolete construct, that does not mean that there is necessarily a problem.  And
it certainly does not mean that _you_ need to do anything about it, beyond
declaring the obsolescence.

Please do not even think about imposing runtime "warnings" about things you
consider obsolete.

So much for what you should not do.  What you should do:

Make clear what you consider deprecated or obsolete.  Make it easy (e.g.
compile-time info) for 3rd-party developers and users to find obsolete
constructs in their code.  That's all.

Leave it up to them how to handle those constructs in their code: whether to
remove them etc.

ST> runtime warnings would severely piss off users (...), enough so
ST> that actively maintained packages would quickly upgrade.

What a wonderful approach that would be.