Deprecated macros

[phst]

Please keep all deprecated macros in the documentation and add the date of deprecation. Also, all robust deprecated macros should produce a warning when called. Otherwise nobody will ever notice that something has been deprecated!

[josephwright]

The problem for me with this is that once a macro is dropped, it should be removed quickly be third parties. (That is why such things are announced on LaTex-L.) What benefit is gained from leaving the macros in the documentation? The idea of leaving the macros available at all is to give a few weeks for people to send CTAN updated code. They will soon know about deprecated functions when stage 2 (removal) takes place!

[phst]

OK, but do you think this will continue once a "final" version (whatever that means) of expl3 is released? Usually deprecated items have to be kept forever. (See e.g. the Java docs on how they handle deprecation.)

[josephwright]

There is certainly a balance between the 'experimental' nature of expl3 and the need to provide stability. Clearly, when we do reach some form of 'release' status, a different approach will be needed (although I'd also expect that we'd not be deprecating many features of expl3 then). One of the problems with expl3 is deciding on the balance between experimentation and usability. My personal view is that we still are not in the position where saying 'these macros are set in stone' is desirable.

[blefloch]

I just had a (probably stupid) idea to put in l3chk: define deprecated functions to be \outer. Then package authors will rapidly realize which functions are deprecated :), at load time (except for a few border cases, where it might be detected at run-time, but detected nevertheless).

[josephwright]

We are now doing this, so I will close this issue.