"Dangerous" packages! What can we do about them (on TeX.sx)?

Question

Two of my friends made all the tables in their thesis using the tabu package. Luckily, I personally did not do so.

Yesterday I learned that it is actually very dangerous to use this package, and that they might not be able to compile their documents in the future anymore:

Is the tabu package obsolete?

When I informed them of this they were – rightfully – upset. Although this package is "dangerous" I can still find 456 results when searching for tabu. This suggests the package is widely used.

My question is how we should best handle such cases. Should we add a remark to answers of questions related to tabu, saying it might be deprecated very soon already?

Or maybe even on a higher level, do you think a package of an author who does not care about his users and does not care if their documents break in the future should even be on CTAN? Clueless users might just find this attractive package and it might only dawn upon them too late which choice they made.

Answer 1

The author made it explicit that the backwards compatibility will be broken. Though the issues are definitely worth fixing, it is still up to the package author to decide how to do that. Making people aware of this fact should be sufficient.

I have to say that I'm not in favor of backwards compatibility that much though. Things should change once in a while.

I can relate to your frustration but I find your attitude quite inappropriate towards a package author. I would definitely not hold grudge against since it was his open source contribution for a long time. Therefore he doesn't have a user base that he is responsible for. He does have a moral obligation but only de facto. You can always find an old version of the package. Especially driving him away is totally unacceptable in my opinion which implies only keep the dudes that are useful and fire them the moment they are obsolete. CTAN is not a company.

Note that the discussion is about whether he should release the package under a different name or overwrite the existing one. Not breaking the existing code on purpose just to have a prank joke. It's not the end of the world though it sucks when things break down.

Answer 2

There are a lot of loaded terms in the description in this question.

There are no easy answers to compatibility. My own packages tend to be very stable and backward compatible but they also have bug reports that have been open for 20 years as they can't really be fixed in a compatible way. Not everyone would say that is better. As @percusse says in his answer it's the package author's call, and in any case an existing document can always use the current package. tabu has some good ideas but it reuses the syntax of the standard array package in an incompatible way, which is an unfortunate choice, but neither that, nor the fact that the package author indicated he had changes planned, makes the package "dangerous".

Answer 3

Nobody but Florent Chervet knows what the next version of tabu will break. There have already been a few backwards incompatible changes between major revisions of the package, but limited in extent. It's a very promising package, because many things are possible with it that weren't before (or required low level tricks).

When I read that message on comp.text.tex I was sorry rather than upset. Sorry for the hundreds of users that risk not being able to compile their document any more, once the new package version is released. I can understand that a major reworking of the package can lead to change decisions made in the past, but a package author shouldn't throw users of his package under the bus.

A case that can be compared is that of caption. Several years ago, a new version with several incompatible changes was released under the name of caption2. Years later, instead of issuing a caption3 package, Axel Sommerfeldt decided to return to caption, having solved many, if not all, compatibility problems.

CTAN hosts revtex4 and revtex4-1, so documents using the old version don't need to be modified. The Koma-Script suite has several <name>2 packages. With mhchem one has to explicitly choose the version=3 option at package loading.

So there are many solutions available. For tabu, unfortunately, the situation is unclear. Use it, if it does good for you, but don't trust on it for archival.

Answer 4

The author of tabu may not be too concerned with backward compatibility, but the maintainers of CTAN are. I corresponded with Robin Fairbairns some time ago about a package I am the maintainer for, and was dissuaded from changing a problem feature, enabled by default, into a package option. CTAN best practice would be to issue the new, improved tabu under a new name, and leave the old one alone. You don't get the improvements, but you can expect to still be able to format your documents after you upgrade.

Whether any particular author follows this advice is a different question. However, it's never difficult to find old versions of latex packages, even if you've upgraded and lost yours. I have some old documents that use an obscure presentation style; after it was incompatibly upgraded, I saved the old version in my personal texmf tree under a different name, and it's been with me ever since. (Meanwhile I migrated to beamer for new documents.)

In short: Don't worry too much about it. You may not get bug fixes and new features, but you'll be able to recompile your documents next year.

Answer 5

As others have already said, equating backward incompatibility with dangerous is a subjective matter.

As a case in point, consider ConTeXt. Compared to LaTeX core, ConTeXt does not assert that new changes will not break backward compatibility. Sometimes, the only way to add new features or to fix bugs is to break backward compatibility, and ConTeXt tends to err on the side to keeping the interface clean at the cost of backward compatibility. As a consequence, it was much easier for ConTeXt developers to move to LuaTeX as the main backend engine; more than 50% of the ConTeXt code is now written in Lua, and is therefore easier to maintain and understand. This rewrite has resulted in renaming of macros (to make the naming scheme consistent) and change in the interface (again to make the interface more consistent). Thus, a document written for MkII does not work for MkIV out of the box. It is expected that the document author will have to tweak the preamble and perhaps make minor changes in the document body as well.

Such a development model is not suitable for everyone. There are those who want stability and backward compatibility over new features and consistency (for example, publishing houses). At the same time, backward compatibility is not suitable for everyone. There are those who would much prefer a nicer interface and new features over backward compatibility (for example, grad students writing a thesis). To each his own.

I think that as long as a package author documents the changes and explains how to translate the old syntax to the new syntax, the package author is being considerate to the users.