# What happens to ArXiV publications when their TeXLive is updated?

ArXiv expects you to upload sources. But - every once in a while - they upgrade their own TeX distribution (e.g. from TL 2011 to TL 2016, last year). This can affect how your document is rendered, and even theoretically break the build.

So, are we supposed to mind our ArXiv-submitted versions every few months and update as necessary? If not, how can this be avoided?

• use bare minimals in your arxiv submissions so if a problem arises, thousands others will suffer too and someone else will solve the issue for you. They do keep some cached pdf/ps for a while, and for often downloaded papers I think. If nobody downloads your contributions, it is not so dramatic if TeX build fails someday. Said tongue in cheek of course! ;-) – user4686 Apr 24 '18 at 13:35
• arxiv.org/help/faq/texlive.html states "Our goal is to provide a stable TeX processing system where we are able to reprocess papers from TeX source at any point in the future. arXiv maintains all past TeX trees such that existing papers are processed using the TeX tree in effect when the paper was originally submitted. This preserves the original presentation (look-and-feel) of the paper." So there should be no problem with submissions that came out OK at the time they were uploaded. – moewe Apr 24 '18 at 14:10
• I guess this is the first time I do not fully agree with @jfbu. I've encountered a number of older arXiv papers that could no longer be compiled. It might very well be that these have been repaired by now, but when I would have needed the pdf file it was unavailable. I know of people who used to add all the style files to the arXiv submission, but since 2005 or so this is no longer tolerated. So I guess what I want to say is that (a) there is not much you can do to make the submission "safe" and (b) you yourself may have to communicate with the arXiv if that happens. – marmot Apr 24 '18 at 14:23
• The trick is to work in a cutting-edge area of science. That way, someone will disprove your results, long before your paper becomes unreadable. I feel sorry for the mathematicians, who expect that their results will be timeless. Or, switch to one of those "Studies" areas in social sciences, where nobody will understand what you're talking about in any case, so there's no loss. – user139954 Apr 24 '18 at 14:43
• I guess the only way to make your submission future-proof is to cut the flamboyant extras and rely on the standard features of LaTeX. Use as little additional packages as possible, avoid low-level features and hacks prefer high-level features instead. Many packages are really stable, but others are actively developed. If development is to move forward it can not always be guaranteed that everything will continue to work as before, some things need to be broken to move on. If there are breaking changes they are more likely to affect lower-level features than the high-level ones. ... – moewe Apr 24 '18 at 15:07

Our goal is to provide a stable TeX processing system where we are able to reprocess papers from TeX source at any point in the future. arXiv maintains all past TeX trees such that existing papers are processed using the TeX tree in effect when the paper was originally submitted. This preserves the original presentation (look-and-feel) of the paper.

and later on

Users may choose to replace older documents where such updates will improve the rendering of documents impacted by bugs in the previous TL2011-based tree.

If you are replacing a paper with older TeX source that rendered fine under the previous release we strongly encourage you to carefully examine your final PDF.

This suggests that papers are rendered with the TeX live version that was used at the time of uploading. So submissions that look fine on the day of upload will continue to do so. There is nothing you have to worry about once you got arXiv to compile your document and are happy with the output.

The general way to be safe here is to use as little packages as possible. Cut down on the bells and whistles and flamboyant output. If you want to use extra packages, try to avoid low-level commands (and \makeatletter...\makeatother hackery of internals) and try to rely on high-level commands instead. High-level commands are more likely to stay stable than low-level (or even undocumented) macros.