Every year TeX Live provides a new version. My recollection is that soon after a new version is released, the old version's tlmgr stops fetching updates to packages. They provide upgrading instructions with the disclaimer

This procedure is not bullet-proof, or especially recommended

There is no upgrade path for Windows. Looking at the release history, it is not clear to me what is actually changing between releases such that a full new install is required/recommended. I always thought of TeX Live as providing useful binaries (e.g., pdflatex, biber, and makeindex) and a convenient way of updating CTAN packages. What am I missing? Why does TeX Live need a new install every year?

  • Maybe just because of legal issues? Apr 5, 2013 at 13:07
  • 1
    I don't think of legal issues, @MarioS.E. Due to legal issues, some packages are removed, if they are not licensed correctly, but this happens automatically during update with tlmgr update command. Apr 5, 2013 at 14:39
  • @StephanLukasczyk, I was thinking of legal issues more as in the way Windows always requires you have the latest drivers, the latest service packs and the latest everything to avoid compatibility issues. If you are not in compliance with this, they simply cannot give you any support Apr 5, 2013 at 14:53
  • 1
    @DanielE.Shub: biber is special case as the binary is built by its developers not TeX Live builders. Apr 6, 2013 at 9:51
  • 3
    biber is built using the excellent Par::Packer module of Perl (and biber is all perl). The build process is not like any other TL binary as a result and it would have been hard to get all the TL servers updated with the necessary things. So I have a build farm of VMs to do this myself. It makes for a more rapid dev cycle as I control the VMs.
    – PLK
    Apr 24, 2013 at 18:50

4 Answers 4


Ok, here's an answer as the main developer of tlmgr and the whole TeX Live infrastructure. You have to decide two things:

  • the freeze period before release of a new version
  • upgradability from one release to the next

Concerning the former, freeze period: Normally during the year we do not make updates to the actual binaries, but only to scripts and the packaging. That means, that in preparation of a new release all the binaries have to be recompiled, which is a huge tasks and involved lots of time, and iterations. Bugs are fixed, code adapted so that it builds on all platforms (and there are many!). During this time we do not want to make partial upgrades of some binaries, because sometimes that needs to be accompanied with library file updates.

Another point is that during the freeze period critical new features are sometimes included in the texlive infrastructure and the tlmgr, which would be too dangerous to be released to the world in the normal course.

And finally, it is also about getting into a state that can be pressed onto DVD.

Now for the upgradability between releases: The reason in the first years were changes in the internals that did not allow upgrades (like format of the internal coding of options, etc.). This was in the first years (say 2008-2010) the most common reason. A normal upgrade was simply not trivially possible. Of course, one could write an upgrade script and make an NSIS installer for Windows, but we do not have time for that. We are volunteers and have to concentrate on the important things.

In the last years (say since 2010) there always was an upgrade procedure, although we normally didn't give it a lot of testing; that is the reason why we don't recommend it. Disk space is nowadays quite abundant, and having two installations in parallel is thus not such a pain. But still, there always was the way to upgrade.

On Windows this is unfortunately not so trivial, as the uninstaller and the registry etc etc is linked to release years, it is simply a pain on Windows, but that is a special case.

Finally, one more reason: In many cases in the last year, an update or a new installation would not have changed much in the amount of downloaded data, as often all the packages were updated in one way or the other (due to internal changes), which meant an upgrade would have involved downloading all packages, just like the installation.

I hope that all this makes our intention a bit more clear, and if there is anything unclear, or if someone has better ideas how to deal with it, we are open to suggestions!

  • 3
    I appreciate this answer from the lead developer. Can you answer the question I posed to @vonbrand in my first comment: why does the entire CTAN tree have to be considered "maintained" by the TeX Live team, to the extent of binding its upgrades to the yearly releases? Whereas with Linux the distro maintainers are to an extent the package maintainers as well, does TeX Live do any patching of packages or just provide them as-is? And if the latter, why not allow continuing updates?
    – Ryan Reich
    Apr 6, 2013 at 15:39
  • 3
    Well, that cannot be answered so easily: For fonts and macros we include everything that is not marked as obsolete and license-wise compatible. Concerning support scripts and programs, there are some requirements (mostly relocability and auto* integration), but other than this the same requirements apply. So in principle, yes, in about 95% of the cases an update of new package on CTAN will end up in TeX Live within a few days.
    – norbert
    Nov 3, 2016 at 22:36
  • 1
    Look into how packages look like on CTAN and how they look in TeX Live! Converting from CTAN, that is how the authors uploaded, to TDS is not trivial.
    – norbert
    Nov 4, 2016 at 3:41
  • 5
    Thank you!! I hadn't even heard of TDS before (that's the level of my ignorance), and with that hint I was able to look up links like tug.org/tds/tds.html and tug.org/texlive/pkgcontrib.html and ctan2tds and ctan2tl and ctan.org/tex-archive/systems/texlive/tlnet/archive etc., which finally answered my question: …(contd) Nov 4, 2016 at 5:32
  • 3
    …(contd): TeX Live does indeed maintain a copy of nearly the entire CTAN tree, because CTAN is not a "proper" package repository; only TeX Live's version is. I've always had a lot of respect for TeX Live but this information shows what a staggering amount of work it is! Thank you… I might write this as an answer to the question sometime, to help others like me (and a few others on this thread I suspect, from the question and comments). This was the most important piece of information that I think those who knew the answer already just took for granted :-) Nov 4, 2016 at 5:32

I can't speak for TeX Live in particular, but I have been involved with Linux distributions from their very beginning, and I believe my observations there are relevant for TeX Live too (both are collections of disparate pieces that have to be selected, integrated and convinced to work nice together, each piece evolves at their own pace).

While in a perfect world such a software collection would be maintained forever, this isn't practical. New packages show up, old packages are overhauled, some packages are superseded by new ways of getting the work done. To maintain, say, TL-2011 would mean to keep "the old way" working, even if upstream has abandoned the package (or changed it so much that it isn't a drop-in replacement anymore). That means endless backporting and fixing old bugs. Volunteers for that are only found among dyed-in-the-wool masochists.

TeX Live maintenance requires knowledgeable people in a rather esoteric area, and those are in very short supply. Either they maintain 2011 forever (and no 2012, 2013, ...) or they concentrate on building and shipping the last version. Besides, working on shiny&new is always more fun, so there is more potential to attract new recruits there.

Perhaps they are enough to keep two versions reasonably up to date, but I guess not (as they have decided that they don't have the manpower, so mandatory yearly upgrade).

  • 2
    Makes complete sense to me Apr 5, 2013 at 13:15
  • 10
    This doesn't answer, though, why the entire CTAN tree needs to be considered "released" on a yearly basis for TeX Live purposes. Though dependencies are resolved by tlmgr, it would be almost trivial to add a switch "--no-deps" that just installs the explicitly requested packages, and make that switch mandatory in outdated releases. Along with forbidding updates of the stuff that's actually maintained by the TeX Live team, this could keep old releases usable indefinitely without extra work. So I interpret the question as asking: why not do this?
    – Ryan Reich
    Apr 5, 2013 at 13:56
  • 1
    Rarely, do I have to do a complete reinstall of my Linux distribution. For example, when Debian moves from Squeeze to Wheezy, upgrading will (hopefully) be as easy as apt-get dist-upgrade. When you "upgrade" TeXLive it downloads all of the packages again from CTAN. That just seems silly (but I am guessing there is a reason).
    – StrongBad
    Apr 5, 2013 at 14:03
  • 2
    That's not what win-win usually means...
    – Ryan Reich
    Apr 5, 2013 at 17:20
  • 4
    Sorry to say, but concerning TeX Live the above fits only partially. We maintain TeX Live without a break, it should be much more considered a continuous development with short breaks in preparation for new binaries and DVD. What is true is that if someone wants, he could check out the svn repo before freeze and continue including package updates using our scripts and distributing them. We don't want to do that, that is all. No time, no space.
    – norbert
    Apr 6, 2013 at 8:23

in addition to @vonbrand's excellent answer, one important reason to upgrade and "freeze" tex live annually is to provide a stable snapshot on physical media, largely for the benefit of members of the various user groups, but also for tex users who don't have convenient internet access.

this dvd (it no longer fits on a cd) is also physically packaged with some (la)tex-related books, particularly in germany; this (commercial) packaging is the reason why anything with a restrictive (non-free) license must be excluded from the collection.

  • 12
    I can understand the need to take and release snapshots. What I don't get is the need to reinstall. It seems tlmgr should be able to update the entire release (it has a mechanism to update itself).
    – StrongBad
    Apr 5, 2013 at 14:33
  • 4
    @Daniel sometimes the format of the database that provides the information changes, and older tlmgr will not be able to use it.
    – norbert
    Apr 6, 2013 at 8:39

To add some more information to the answers of @vonbrand and @barbara beeton:

One other reason is to change infrastructural things. Some time ago the tlmgr management tool was introduced with a graphical interface for (mainly) windows users. Also the package format was changed (I think it was from TL2008 to TL2009) from LZO to XZ which was not possible if not requesting a new installation as the whole infrastructure was changed.

But nevertheless it often is possible to update e.g. from TL2011 to TL2012 without any new full installation. But be careful: This is not supported by the developers and is not recommended! It works in some cases and in others not.

I have an hope that there will be kind of a rolling release scheme (as e.g. in Arch Linux or Gentoo), as this was a topic several times on TeX Live's mailing list.

  • 2
    I can see how changing the package format would require a reinstall. Interestingly, the TL team put the change to XZ under a miscellany of smaller changes
    – StrongBad
    Apr 5, 2013 at 17:51
  • 2
    @Daniel E. Shub This was kind of an understatement;-) Apr 5, 2013 at 22:47

You must log in to answer this question.

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