Ist es sinnvoll Entwicklerversionen von Paketen an Stelle der offiziellen, stabilen Version zu verwenden?

Diese Frage ist nicht ganz leicht zu beantworten, da dabei verschiedene Aspekte eine Rolle spielen. Da ist zum einen die Frage der Installation, zum anderen die Frage der Verwendung.

Typen von nicht stabilen Versionen:

Zunächst ist zwischen daily snapshots, Repository-Versionen und Beta-Versionen zu unterscheiden.

Im Repository (beispielsweise CVS, Subversion, Git u. v. m.) ist in der Regel der brand-aktuelle Entwicklungsstand (aka trunk) zu finden. In der Regel gibt es keinerlei Informationen darüber, inwieweit dieser getestet ist. In Einzelfällen kann es sogar sein, dass man aus dem dort befindlichen Quelltext wegen eines Fehlers gar keine funktionierenden Pakete erzeugen kann. Teilweise findet man aber auch stabilere Entwicklungszweige (aka branches), die gesondert gekennzeichnet sind. Sie alle werden im Folgenden als Entwicklerversionen bezeichnet.

Daily Snapshots werden in der Regel vollautomatisch aus dem Repository erzeugt. Damit fallen sie ebenfalls in die Kategorie Enwicklerversionen.

Beta-Versionen sind hingegen spezielle von den Entwicklern freigegebene Versionen, die meist gewisse Mindesttests erfolgreich bestritten haben und deren Anwenderschnittstelle zwar nicht unveränderlich ist, aber durchaus in dieser Form für zukünftige stabile Versionen geplant ist. Zu Testzwecken ist die Verwendung ausdrücklich erwünscht.

Folgen der Installation und Verwendung nicht stabile Versionen

Bezüglich der eigenen LaTeX-Installation ergibt sich durch die Installation von Entwicklerversionen oder Beta-Versionen von Paketen das Problem, dass die Verwaltung aufwändiger wird. Während die Paketversionen, die von der jeweiligen TeX-Distribution bereit gestellt werden, leicht über den Paketmanager der TeX-Distribution verwaltet und aktuell gehalten werden können, muss man bei den manuell zu installierenden Entwicklerversionen zunächst lernen, wie man diese korrekt installiert, und dann jedes einzelne Paket ggf. selbst aktuell halten.

Bezüglich der Verwendung von nicht als stabil gekennzeichneten Versionen ergibt sich das Problem, dass diese in der Regel weder gut getestet sind, noch sichergestellt ist, dass alle Features bei der nächsten Entwicklerversion oder der nächsten stabilen Version noch in gleicher Weise funktionieren. Daher kann es sowohl sein, dass ein existierendes Dokument mit der Entwicklerversion nicht mehr funktioniert, als auch, dass ein mit der Entwicklerversion neu erstelltes Dokument mit der nächsten Version nicht mehr funktioniert. Darüber hinaus kann es auch sein, dass andere Pakete, die mit diesem Paket zusammenarbeiten (müssen) noch nicht mit der aktuellen Entwicklerversion zusammenarbeiten, bzw. für diese anderen Pakete dann ebenfalls Entwicklerversionen notwendig sind. Dieses Problem kann sich aufschaukeln.

Auf der anderen Seite ist es so, dass Entwickler meist froh sind, wenn ihre öffentlich zugänglichen Entwicklerversionen möglichst früh von möglichst vielen Menschen getestet werden. Nur so kann sichergestellt werden, dass möglichst viele Fehler und Designschwächen frühzeitig erkannt werden.

Manchmal ist man zur Lösung für ein Problem, sei es aufgrund eines Fehlers in einem Paket oder schlicht aufgrund eines neuen Features in der Entwicklerversion, auch auf eine Entwicklerversion angewiesen. Dann bleibt einem kaum eine Wahl, trotzdem sollte man sich über die Risiken und Nachteile im Klaren sein.

In der Regel ist es also empfehlenswert für den produktiven Einsatz möglichst nur stabile Versionen und in erster Linie die vom Paketmanager der jeweiligen TeX-Distribution bereitgestellte Versionen von Paketen zu verwenden. Für den temporären Einsatz von Entwicklerversionen bietet es sich an, einen eigenen TEXMF-Baum (aka TDS-Baum) anzulegen.

Möglichkeiten zur Verwendung einer nicht stabilen Version

Bei MiKTeX geht das Anlegen eines weiteren TEXMF-Baums für Entwicklerversionen einfach über die Einstellungen. Das geht so einfach, dass man sogar für jedes Entwicklerpaket einen eigenen TEXMF-Baum anlegen kann. Diesen kann man dann nach Bedarf aktivieren und deaktivieren.

Bei TeX-Live bietet sich theoretisch der private TEXMF-Baum für Entwicklerversionen von Paketen an. Allerdings ist das nur dann wirklich sinnvoll, wenn man für Tests einen eigenen Benutzer hat. Anderenfalls ist es besser, einen neuen TEXMF-Baum anzulegen und diesen beispielsweise über das lokale Setzen der Umgebungsvariablen TEXMF zu aktivieren. Linux-Anwender könnten dazu beispielsweise ein Script wie

    #!/bin/sh
    TEXMF="$HOME/texmf-beta//:$( kpsewhich -var-value=TEXMF )"
    export TEXMF
    pdflatex "$@"

anlegen und dieses an Stelle von pdflatex aufrufen. Dieses erweitert den Suchpfad um die Komponente $HOME/texmf-beta, also einen TEXMF-Baum namens texmf-beta im Benutzerverzeichnis, wobei dieser TEXMF-Baum ggf. komplett durchsucht wird. Es ist also nicht notwendig, dafür texhash aufzurufen.

Statt in der letzten Zeile pdflatex aufzurufen, kann man dort auch den bevorzugten LaTeX-Editor aufrufen. Dann arbeitet dieser und alle von ihm gestarteten Programme mit dem erweiterten TEXMF, also auch pdflatex, makeindex, bibtex oder biber.

Benötigt man eine Entwicklerversion ausschließlich für ein einzelnes Dokument, so gibt es außerdem die Möglichkeit, die Paketdateien der Entwicklerversion im entsprechenden Dokumentverzeichnis abzulegen. Dort werden die Paketdateien in der Regel als erstes gesucht und gefunden. In diesem Fall entfällt auch die aufwändige Verwaltung bezüglich zukünftiger, neuerer Versionen, da die Entwicklerversion ja genau die Version ist, die für dieses Dokument relevant ist. Allerdings muss man dann bezüglich der Weitergabe des Dokumentquelltextes darauf achten, dass die Lizenzbedingungen des Pakets, das zusammen mit dem tatsächlichen Dokumentquelltext weitergegeben wird, eingehalten sind.