Re: Obsoleting more progressively

[jasonr]

Quoting Stefan Monnier <address@hidden>:

> I can think of 2 ways to do implement that second level of obsolescence:
> - Add warnings at runtime when obsolete stuff is used.
>   for functions, commands and macros, make-obsolete that's reasonably
>   easy to do; for variables it's more difficult.
>   For hooks, we could let add-hook check the obsolescence property and
>   emit a warning, and similarly for a few difference cases, but for
>   the primitive get&set operations, this is not an option.
> - Actually remove the function/variable from the non-released code.
>   I.e. remove/deactivate the functions/variables from trunk during
>   development but put them back in when we start pretesting.
>
> Any thoughts?

Another possibility is to leave the elisp there, but needing some explicit
action to load it. Maybe a new function (load-obsolete "file") to load such
files, or (use-obsolete 'feature) to enable loading that feature with the usual
functions. This assumes whole files that have been obsoleted - if it is the odd
variable or function within a still current package, then they should probably
be moved to a new file in the obsolete directory first.