Re: Obsoleting more progressively

[Stefan Monnier]

> FWIW, I suspect much of the problem you are trying to solve is due to
> no-one paying attention to the warnings.

Yes, currently the obsolescence info is only displayed in docstrings and
in byte-compiler warnings.  So it's relatively easy for a piece of
oldish code to spend 10 years without anyone seeing these (except for
people who can't do much about it and are just happy that it still
works).

> Either because the package is unmaintained but still in use, so there
> is no-one there to deal with the warnings (eg recent old-style
> backquotes stuff), in which case trying to make it fail more gradually
> makes no difference to the final result; or because people just ignore
> the warnings.

My expectation is that if we make it half-break after 5 years (say), we
might expect that someone will fix it in less than 5 years, so that
after a total of 10 years noone will suffer when we actually remove
the feature.

>> - 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.

> You could combine 1 with 2 by having some flag that says whether using
> an obsolete thing triggers an error or a warning. Set it to error
> during development, and to warning for a release.

I currently like the obsolete-<foo> renaming suggestion.  We can then
provide commands (or even a Custom var) to add the necessary aliasing to
make it work, and those vars/commands can very well emit a warning at
startup.

> Un-thought-out plan: when compiling foo.el, put a comment marker at
> the end of the file giving the obsolescence version of the oldest
> obsolete feature that it uses (if any).

That won't help people who're using a .elc (or even a .el) file they
got 15 years ago.


        Stefan