11

When programming, I take some care regarding updating of external dependencies, to be sure that my code isn't affected. With LaTeX (I'm using MikTeX), it seems harder to know when I should update packages. In programming, my big concern is the possibility for errors or interface changes. With LaTeX packages, this is a concern, but it seems it's also possible for documents compiled with one version of a package to look quite different when compiled with a changed version. Separately, I've asked a different question regarding automatic regression testing of compiled documents.

How should one know when to update and whether the update is worthwhile? If it helps, I'm focusing on using MikTeX and CTAN.

Note 1: This question differs from this one as I am focused more on the practices of updating, rather than the setup of MikTeX.

This question is interesting regarding keeping informed about obsolete and recommended alternative packages, but differs because I am focused issues that affect many files, rather than just thinking about how to better use a given package. Some older files don't necessarily need to be reworked (e.g. things that have been published).

Community
  • 1
Iterator
  • 365
  • Are you thinking primarily as an end-user or as a package/class developer? – Joseph Wright Feb 28 '12 at 20:11
  • @JosephWright As an end-user, but testing as a package/class developer would certainly be an interesting question. However, I'm not the one to ask it - I'm not yet motivated to reach that level of proficiency. :) – Iterator Feb 28 '12 at 21:55

2 Answers2

13

As an academic instructor teaching "Technical writing with LaTeX", I advise my students as follows.

  1. At the beginning of each semester go the MikTeX maintenance menu and run a complete update.
  2. If you load a new package and strange things happen, do a full update.
  3. If you are going to send source code to another person which must run correctly then run the update before you send it off. (This includes MWE for problem solving).
  4. And you must update no later than every two years or you will have problems with the latex base package.
N.N.
  • 36,163
R. Schumacher
  • 9,895
  • This is a good answer. Can you clarify why there would be problems biannually with the base package? Is there an update schedule? (Moreover, thinking in terms of Nyquist-Shannon, is that interval 4 years? ;-)) Or is this a rule of thumb? – Iterator Feb 29 '12 at 15:43
  • It is a rule of thumb. As I work with students, it is difficult to debug problems unless the individual installations are current. Packages can specify a not older than version for successful loading. And several journal style files check the version of the latex kernel, and if it is not recent enough you will get errors. – R. Schumacher Mar 12 '12 at 23:50
  • Related http://tex.stackexchange.com/questions/47743/require-a-certain-or-later-version-of-a-package – R. Schumacher Mar 12 '12 at 23:54
6

I suggest a different approach: Maintain a project-specific texmf folder with exactly those packages and package versions you need.

Background

I frequently collaborate with others on LaTeX-based projects. We use a revision control system (subversion), but besides... Well, you know: Everybody has a different LaTeX installation on various operating systems, some still run a broken TexLive 2009 on Debian and many are either not willing or not able to update.

All this caused me a lot of troubles – until I started to manage a project-specific texmf folder for each project. I just check in any "newer" or "uncommon" package I use into the project-specific texmf folder, so that an svn up on the side of my collaborators also updates the necessary packages. Of course, I have to make sure (via the project-specific Makefile, a source.me scripts for various shells and drivers for common LaTeX front-ends, such as TexShop or latexmk), that the project-specific texmf tree is the first in TEXINPUTS and colleagues.

Of course, I do not check in every used package. Most LaTeX packages have been pretty stable over the last couple of years, so they are most probably available on everyones installation. Others, such as biblatex, pgf or adjustbox are under active development or not yet part of "standard" distributions; newer versions may bring compatibility-breaking changes. These packages are checked in into the project-specific texmf folder.

Result

In the beginning, it required a bit of experience to get to "know" the (probably) problematic packages, but meanwhile, this works pretty well: Older project that used "beta"-packages of their time and would no longer compile with a current LaTeX distro can still be compiled. The same holds for current projects that use uncommon or "beta" package and would not compile with anything, but the most recent LaTex distro.

Daniel
  • 37,517
  • That's an interesting and reasonable approach. It certainly adheres to the principles of reproducible research. However, do you end up accumulating a lot of files? – Iterator Feb 28 '12 at 21:58
  • @Iterator: Well, some packages (such as TikZ/PGF) are somewhat bigger, but so what. As I wrote: I do not check in every package, which probably would be the clean approach regarding "100% reproducability". For really important projects, however, I have done this in the end: I extracted (via pdflatex -recorder) the list of all packages and classes that are actually used and copied all of them to the project-specific texmf tree. This can take up a few MiB, of course. – Daniel Feb 28 '12 at 22:05