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`) *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`), *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 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 ist, 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][1]) 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 <pre> #!/bin/sh TEXMF="$HOME/texmf-beta//:$( kpsewhich -var-value=TEXMF )" export TEXMF pdflatex "$@" </pre> 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. [1]: http://www.ctan.org/pkg/tds

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 ist, 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][1]) 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 <pre> #!/bin/sh TEXMF="$HOME/texmf-beta//:$( kpsewhich -var-value=TEXMF )" export TEXMF pdflatex "$@" </pre> 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. [1]: http://www.ctan.org/pkg/tds

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 sie 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 ist, 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][1]) 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 Benutzrverzeichnis, 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. [1]: http://www.ctan.org/pkg/tds

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 sie 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 ist, 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) [TDS-Baum][1]) 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 Benutzrverzeichnis, 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. [1]: http://www.ctan.org/pkg/tds

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 sie 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 ist, 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 Benutzrverzeichnis, 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 **für ein einzelnes Dokument, 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.

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. 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 sie 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 ist, 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. **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 Benutzrverzeichnis, 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.

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. 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 sie dann für 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 ist, 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. **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 Benutzrverzeichnis, 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`.

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. 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 sie dann für 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 ist, 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. **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 Benutzrverzeichnis, 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`.