TeXLive is big, but not enormously so by today's standards.
I would strongly recommend installing and maintaining the full distribution; otherwise you'll likely waste a lot of your time installing packages "as you discover them".
This way, you'll be able to "carry on writing" without interrupting the flow.
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!
Best Answer
TeX Live consists of a relatively small number of executable items and a large number of 'other things', principally LaTeX packages, fonts and documentation (PDF files). The standard settings for the binary part of the set up are 'cautious' about potential security risks in the (La)TeX parts of the system, but these are likely to be more theoretical than actual. To the best of my knowledge there has not been an attempt to send to CTAN, and thus to TeX Live, a LaTeX package which deliberately tries to use
\write18to cause trouble. The number of people who would be affected is very small, and it's extremely unlikely that a self-replicating approach would be successful. The binary parts of the system are of course of more interest in this regard, but again there are not to my knowledge any actual issues (though see Is luatex as secure as pdftex? for discussion on the affect of Lua scripting on security).All of that said, there is no-one checking each CTAN upload for security fixes, and the TeX Live team take most of their material more-or-less directly from CTAN. As such, if you are looking for some form of 'assurance' on the code then you will have to find a downstream group doing the work. That I know of, Ubuntu do not do this, although you might be better asking on an Ubunut-specific site about that. Perhaps other operating system teams (most obviously OpenBSD) might do such work if they are very security-focussed, but again that is more about those systems than about TeX.