Dear all, I have a package with a legacy main function which calls a few exported functions. In practice most users will only call the main function. Should I deprecate only the main function or all the legacy functions? The latter case generates more deprecation warnings when calling the main function. Best regards, ir. Thierry Onkelinx Statisticus / Statistician Vlaamse Overheid / Government of Flanders INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND FOREST Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance thierry.onkelinx at inbo.be Havenlaan 88 bus 73, 1000 Brussel www.inbo.be /////////////////////////////////////////////////////////////////////////////////////////// To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey /////////////////////////////////////////////////////////////////////////////////////////// <https://www.inbo.be>
[R-pkg-devel] which functions to deprecate
2 messages · Thierry Onkelinx, Duncan Murdoch
On 11/10/2021 7:06 a.m., Thierry Onkelinx wrote:
Dear all, I have a package with a legacy main function which calls a few exported functions. In practice most users will only call the main function. Should I deprecate only the main function or all the legacy functions? The latter case generates more deprecation warnings when calling the main function.
I'd say you should deprecate all the functions you intend to stop exporting two releases from now, i.e. they'll all be deprecated in the next release, and defunct in the release after that. If you find that calling the main function generates too many messages, then you could leave the others undeprecated for now, and deprecate them when you finally mark the main one as defunct (or delete it). That is: next release: main is deprecated next+1 release: main is defunct, others are deprecated next+2 release: all are defunct Alternatively, you could deprecate all of them now, but edit the main one so it suppresses the deprecation messages in the others. Deprecation messages are documented to have class "deprecatedWarning", so you can suppress only those messages if you work at it. Duncan Murdoch