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.
    – user30471
    Oct 25, 2014 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, 2014 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, 2014 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. Oct 25, 2014 at 18:43
  • [...] there is no reason for anyone to use my package anymore. How do you know?
    – enthu
    Oct 26, 2014 at 6:51

2 Answers 2


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


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, 2014 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, 2014 at 23:05
  • @cfr perhaps both? Anyway that link could be the basis of a very good answer.
    – David Z
    Oct 25, 2014 at 23:25
  • 1
    This has been tangentially discussed here; meta.tex.stackexchange.com/questions/3859/… @DavidZ doesn't own anything to anyone and also trying to be helpful to provide alternatives. This is not a nice way of appreciating the efforts. They are not serving you and they can do anything they want. Out of courtesy they can make it graceful or be stubborn and cut the cord. We are not in place to judge the decision on ethical standards....
    – percusse
    Nov 5, 2014 at 13:40
  • 1
    .... Especially I won't blame anyone if they cut the cord immediately after this kind of response. You can always store the old version of the package and live with it. CTAN is not an app store.
    – percusse
    Nov 5, 2014 at 13:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .