31

I maintain a LaTeX package which is obsolete. All its useful commands are provided by other packages, possibly with different syntax, but still the point is there is no reason for anyone to use my package anymore. Anyone who wants its functionality should use the other packages that replace it.

Are there any best practices I should use to "retire" my package? In other words, to push people away from using it and toward the other packages that replace it?

As an extreme example, one thing I could do is upload a new version of my package to CTAN in which the entire contents is deleted and replaced with

\PackageError{mypackage}{mypackage is obsolete!}{%
  See the documentation for what you should be using instead}

or something along those lines. This would more or less force people to stop using my package. But according to this answer it's desirable that old LaTeX documents should still compile correctly, and this extreme solution spoils that. Perhaps deprecation using a \PackageWarning would be better? Or something else entirely? (Does CTAN have any special support for deprecating a package?)

But again, that is only an example. I am asking for any best practices that are recognized by experienced package authors, or have been successfully used in the past, when it comes time to mark a package as obsolete.

  • 10
    As you say, it's desirable to keep the package so that old code will still compile. Why don't you just add a \PackageWarning and a note at the start of the package documentation saying that the package is depreciated and that people should use X, Y and Z. – Andrew Oct 25 '14 at 7:18
  • 1
    You could change the syntax to be excruciatingly impractical to use / user-unfriendly... :-D -- Just kidding, I'd go with Andrew's suggestion. – 1010011010 Oct 25 '14 at 8:26
  • 4
    CTAN has an "obsolete" branch. Pehaps in addition to @Andrew's suggestion, you could somehow get the package moved over there. (Probably doesn't really stop people from newly using the package, but I'm not sure how you can prevent that.) – jon Oct 25 '14 at 15:19
  • 4
    I have a package (stackengine) in which some of its original syntax became obsolete, and incompatible with the revised syntax. What I did when implementing the improved syntax was to create a package option that allowed the obsolete syntax to be invoked. So, in this way, you could make the package load issue an error message, unless the user added the [UseItAnyway] (or whatever) option to his invocation, if he really wanted to continue its use. The error message could even alert the user to the existence of the [UseItAnyway] option. – Steven B. Segletes Oct 25 '14 at 18:43
  • [...] there is no reason for anyone to use my package anymore. How do you know? – Enthusiastic Engineer Oct 26 '14 at 6:51
16

I don't think that there is a single best practice --- it partly depends in what way your package has become obsolete.

One of the strong goals of LaTeX is continued backward compatibility, i.e., the ability to reprocess old documents successfully even after a long period of time and in fact that is something tat most of the time works surprisingly well (e.g., even LaTeX 2.09 documents usually compile straight away even though they give you a bold warning).

To make this possible old/obsolete packages need to be still around and available in some shape or form.

Now how they are being available depends on the nature of "obsolete": if your package has enhanced some functionality of some other package and this is now incorporated in the other package (perhaps with a slightly different interface) the best way forward may be to simply to emulate your package using the current one. For example in the graphics space many packages existed initially (epsfig, rotating, ...) and I think all of them are, but rotating for example, nowadays only preserves its interface (options) but then internally passes everything to the graphics package to do the work.

If, however, your package (or class) cuts across many other packages and provides functionality extensions here and there this approach may not be viable as the danger of introducing subtle issues is probably greater than its gain. In that case may recommendation would be to only generate a (bold) warning, explaining how it could be replaced but then let it run its course.

There is a debate on whether or not that bold warning should stop processing (so that the user need to press return to continue) or that it should be only a screen warning that flashes by. Personally, I think for material that really needs weeding out and would best be replaced, making a stop is better than just issuing a warning (as most people will not see a warning or even if they see will not care if it is just a warning). But as I said this is being hotly debated. Recently I wanted to introduce an error into inputenc in case of badly wrong input (that could result in wrong output without any information to the user) and many people objected, because the stop would also happen in a few cases where the input was technically wrong but the output not affected ... so in summary best practice may be seen as "ensure that user support for existing documents is not (badly) affected by your approach".

7

It would be very rude to all the users who rely on your package to swap its function for an error message. I can not understand how someone ever could consider such a reckless approach. Some years ago the maintainer of Linux Libertine cut the support for pdftex and I found myself in the middle of my work towards a deadline trying desperately to get the backup running -- after wasting precious time to investigate, why all of a sudden my file did not compile!

What you are asking is not to "retire" your package, but you don't want to maintain it any longer.

Dear package author, thank you very much for your package and for maintaining it years and years. What's left to do is to mark it as "unmaintained" in the manual and make a last update to CTAN.

  • No, it seems you've misinterpreted my question. It is not true that I don't want to maintain the package anymore. I fully intend to continue serving as the package maintainer. The issue is that the package itself is useless. It merely duplicates functionality provided by other packages, so there is no reason for anyone to use it. The essence of my question is how to properly indicate to people that they should not use my package anymore. – David Z Oct 25 '14 at 22:16
  • 1
    @DavidZ If I find a bug in your package, will you fix it and update the package? Or will you tell me I should use something else anyway? If it is really useless, what is the point of maintaining it? Here is the kind of thing you probably want on CTAN. – cfr Oct 25 '14 at 23:05
  • @cfr perhaps both? Anyway that link could be the basis of a very good answer. – David Z Oct 25 '14 at 23:25
  • @DavidZ If you'd fix it, I am not sure it can be properly considered 'obsolete' in the sense it seems to be used for TeX packages. I can't really quite figure out what you want the status of the package to be. Do you just want to give users some advice? Then put some warnings in the console output and documentation. The lastpage package has done this for some time, I think. If you declare it truly deprecated/obsolete, I think you need to be clear that you won't fix bugs (except maybe bugs which would prevent older documents from compiling with newer TeX installations). – cfr Oct 26 '14 at 0:37
  • @cfr what I want is to advise anyone considering using my package that they should no longer use it, in the strongest terms reasonable. I guess I'm coming at this from the mindset of other programming languages, where some piece of code can be designated "deprecated" or "obsolete" to indicate that the code is bad in some way that will not change in future versions, and should be avoided. Perhaps it contains subtle unfixable errors, or is just stylistically undesirable. Whatever the equivalent status is in LaTeX, I want my package to have it. – David Z Oct 26 '14 at 0:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.