Report replacement/version in `define-deprecated-command` ?

[Ambrevar]

Questions:

• If we deprecate a command, shall we remove it for the next major release? If so, then no need to report the version in which a command was deprecated, because it can only be the last one.
• We should probably echo / log:warn some text explaining with what code the command should be replaced.
• Do we still need the define-deprecated-command macro? Maybe it's enough to just do

(define-command foo (...)
 ...)
(setf (deprecated-p #'foo) t)

Thoughts?

[Ambrevar]

SBCL has a nifty feature actually:

http://www.sbcl.org/manual/#Deprecation-Examples

[Ambrevar]

As @aartaka suggested, we can then reintroduce some migration helpers, like:

• Import make-autofill in nyxt.
• nyxt-init-file to expand to nyxt-config-file.

[aadcg]

This an important thread so that we have better deprecation practices for 4.0.0 and forward.

---

If we deprecate a command, shall we remove it for the next major release?

I'd say yes because Nyxt is still a moving target. In the future, we can have a more conservative policy.