Julia 1.13 nach der Veröffentlichung für Forschungsprojekte sollten Sie in der ersten Woche nicht direkt über die bestehende Produktionsumgebung installieren: Frieren Sie zuerst den funktionierenden Stand ein, testen Sie Julia 1.13 separat und entscheiden Sie erst danach zwischen Upgrade, Parallelbetrieb oder Aufschub. Für neue, noch nicht produktive Projekte kann Stable früher eingesetzt werden, sofern Paketauflösung, numerische Ergebnisse und der Rückfallweg dokumentiert sind.

Diese Anleitung ist für drei Gruppen gedacht: Paketentwickler, die Julia-Pakete und CI prüfen müssen; Studierende und Forschende, die die Reproduzierbarkeit einer Arbeit schützen wollen; sowie technische Verantwortliche, die eine gemeinsame Hochschulumgebung verwalten. Sie erhalten keine Liste neuer Funktionen, sondern eine zeitlich geordnete Prüfung mit klaren Abbruchkriterien.

Letzte Aktualisierung: 20.09.2026. Versionsstand und Installationswege wurden anhand der offiziellen Julia-Downloadseite und der offiziellen Plattformübersicht geprüft.

Ausgangslage und Entscheidungsrahmen

Die offizielle Julia-Quelle führt Julia 1.13.0 zum genannten Prüfzeitpunkt als Stable-Version und stellt daneben Informationen zu LTS, älteren Versionen und unterstützten Plattformen bereit. Das bestätigt den verfügbaren Release-Stand, aber nicht automatisch die Eignung für Ihr konkretes Forschungsprojekt. Paketkompatibilität, numerische Ergebnisse und Laufzeitverhalten müssen mit den tatsächlichen Modellen und Daten Ihrer Arbeitsgruppe geprüft werden. Die Veröffentlichung selbst ist daher ein Startsignal für die Validierung, kein Freibrief zum Überschreiben der bisherigen Umgebung.

Besonders riskant ist ein sofortiger Wechsel aus vier Gründen:

  • Reproduzierbarkeit: Eine bisher erzeugte Tabelle oder Abbildung kann mit einer veränderten Paketauflösung, einem anderen Solverpfad oder abweichenden Zufallsbedingungen anders ausfallen, obwohl das Skript weiterhin startet.
  • Paketabhängigkeiten: Ein direkt verwendetes Paket kann kompatibel erscheinen, während eine indirekte Abhängigkeit oder eine native Bibliothek die Installation verhindert. Ein erfolgreiches using-Statement deckt diese Fälle nicht vollständig ab.
  • Betriebssicherheit: CI-Läufe, Batch-Skripte, Dokumentations-Builds und Exportpfade können an einer anderen Stelle scheitern als der interaktive Notebook-Test.
  • Rückfallkosten: Wenn Sie die bisherige Umgebung überschreiben, müssen Sie Versionen, Artefakte, Umgebungsvariablen und lokale Anpassungen nachträglich rekonstruieren.

Die Julia-Dokumentation beschreibt Project.toml und Manifest.toml als zentrale Dateien zur Festlegung und Wiederherstellung einer Paketumgebung. Sichern Sie deshalb beide Dateien gemeinsam mit den Startbefehlen und dem verwendeten Julia-Pfad; nur eine lose Paketliste reicht für eine belastbare Rekonstruktion nicht aus. Die Dokumentation zu TOML-Umgebungen erklärt die Rolle dieser Dateien.

Entscheidungswerkzeug für die erste Woche

Option Geeignet, wenn Nachweis vor der Entscheidung Rückfall
Upgrade Kernpakete, numerische Referenzen, CI und Dokumentation ohne ungeklärte Abweichung funktionieren Reproduzierbare Ergebnisse und gelöster Installationsweg Gesicherte alte Umgebung erneut aktivieren
Parallelbetrieb Julia 1.13 technisch funktioniert, aber einzelne Pakete oder externe Abhängigkeiten noch beobachtet werden müssen Vergleichbare Testläufe mit klarer Kennzeichnung der Julia-Version Produktionsjobs bleiben auf dem alten Stand
Aufschub Paketstatus unklar ist, Ergebnisse abweichen oder ein Rückfall nicht sicher möglich ist Offene Punkte, Verantwortliche und neuer Prüftermin Keine Änderung an der produktiven Umgebung

Bewerten Sie diese drei Optionen nicht nach Versionsneuheit, sondern nach dem Verhältnis aus Ergebnisrisiko, Wartungsaufwand und Zeitpunkt Ihrer wissenschaftlichen Abgabe. Ein laufendes Experiment mit festgelegten Referenzwerten verdient eine andere Entscheidung als ein neues Projekt ohne veröffentlichte Ergebnisse.

Veröffentlichungstag: Beweise sichern

Am Veröffentlichungstag beginnt die Arbeit mit einer Bestandsaufnahme. Schreiben Sie nicht nur „Julia aktualisiert“, sondern halten Sie den Zustand fest, den eine andere Person später wiederherstellen muss.

  1. Julia-Version und Installationsquelle notieren: Speichern Sie die Ausgabe von julia --version, den vollständigen Pfad der ausführbaren Datei und den verwendeten Installationsweg. Die offizielle Julia-Release-Ankündigung dokumentiert den Release von Julia 1.13.0; sie ist jedoch kein Beleg dafür, dass Ihre Pakete bereits angepasst wurden. Verlinken Sie die offizielle Ankündigung zu Julia 1.13.0 in Ihrem internen Prüfprotokoll.

  2. Projektdateien archivieren: Kopieren Sie Project.toml, Manifest.toml, Skripte, Konfigurationsdateien und die CI-Definition in einen unveränderlichen Archivstand. Ergänzen Sie den Commit, die Betriebssystemversion und alle Umgebungsvariablen, die das Ergebnis beeinflussen.

  3. Repräsentative Referenzen auswählen: Nehmen Sie nicht jedes Notebook in den ersten Test auf. Wählen Sie mindestens ein Modell oder Skript, das für die Forschungsfrage entscheidend ist, einen typischen Datenimport, einen relevanten Export und eine Ausgabe, die fachlich beurteilt werden kann.

  4. Ergebnisse mit Kontext speichern: Tabellen und Grafiken allein genügen nicht. Bewahren Sie Eingabedaten, Parameter, Zufallsseed, Laufprotokoll und die verwendete Umgebung auf. Bei sensiblen Forschungsdaten sollten Sie außerdem prüfen, ob der Speicherort und die Zugriffsrechte mit Ihren institutionellen Datenschutzvorgaben vereinbar sind. Die Datenschutzerklärung von SSHMac kann dabei ergänzende Informationen zur Verarbeitung personenbezogener Daten liefern, ersetzt aber keine Freigabe durch Ihre Hochschule.

  5. Gerüchte von bestätigten Informationen trennen: Aussagen aus Foren oder sozialen Netzwerken können Hinweise auf Probleme liefern, sind aber keine allgemeine Kompatibilitätsaussage. Kennzeichnen Sie solche Beobachtungen als unbestätigte Community-Rückmeldung und reproduzieren Sie sie mit Ihrem Projekt, bevor Sie daraus eine Upgrade-Sperre ableiten.

Am Ende dieses Abschnitts muss der alte Stand startbar und auffindbar bleiben. Wenn Sie diesen Zustand nicht zuverlässig wiederherstellen können, ist der nächste Schritt kein Upgrade, sondern die Reparatur Ihrer Sicherungs- und Dokumentationspraxis.

Erste Stunde: isolierte Stable-Umgebung

Für Julia 1.13 benötigen Sie eine Umgebung, die neben der bisherigen Installation existieren kann. Die offizielle Downloadseite beschreibt sowohl juliaup als auch manuelle Installationswege. Wählen Sie einen Weg, den Ihre Arbeitsgruppe später reproduzieren kann, und notieren Sie dabei Plattform, Architektur und Installationsquelle.

Die Prüfung sollte in dieser Reihenfolge erfolgen:

  1. Erstellen Sie einen separaten Branch oder ein eindeutig benanntes Testverzeichnis. Vermeiden Sie Änderungen am Branch, aus dem Ihre laufenden Publikations- oder Batchprozesse starten.
  2. Installieren Sie Julia 1.13 über einen dokumentierten offiziellen Weg. Verwenden Sie keine nicht nachvollziehbare Binärdatei und übernehmen Sie nicht blind globale Einstellungen aus Ihrer bisherigen Installation.
  3. Starten Sie die neue Version einmal interaktiv und einmal über den später verwendeten Skript- oder CI-Aufruf. So erkennen Sie Unterschiede bei Pfaden, Umgebungsvariablen und Startargumenten.
  4. Aktivieren Sie die gesicherte Projektumgebung zunächst ohne inhaltliche Änderungen. Prüfen Sie, ob die Paketauflösung mit dem vorhandenen Manifest gelingt.
  5. Protokollieren Sie Auflösungsdauer, Warnungen, fehlende Artefakte, native Bibliotheken und die Methode zur Wiederherstellung. Die Zeitangabe ist kein Leistungsbenchmark; sie ist ein Diagnosewert für Ihre konkrete Umgebung.
  6. Prüfen Sie die Architektur getrennt. Auf Apple Silicon kann eine native Abhängigkeit anders bereitgestellt werden als auf Intel. Eine erfolgreiche Ausführung auf Linux oder einem Intel-Mac beweist deshalb nicht, dass dieselbe Umgebung auf Apple Silicon funktioniert.

Für Paketentwickler ist außerdem der Kompatibilitätseintrag der eigenen Bibliothek relevant. Die Julia-Paketdokumentation zu Kompatibilitätsregeln beschreibt, wie unterstützte Julia- und Paketversionen festgelegt werden. Ändern Sie diese Angaben nicht nur, damit der Resolver eine Installation akzeptiert. Ein breiterer Kompatibilitätseintrag ohne Testabdeckung verschiebt das Risiko lediglich auf die Nutzer.

Wenn Ihnen kein eigener Mac zur Verfügung steht, können Sie eine tatsächlich erreichbare Apple-Silicon-Umgebung als separaten Validierungsschritt verwenden. Dabei müssen Sie Fernzugriff, Konten, Datenlöschung und die Verarbeitung personenbezogener oder unveröffentlichter Daten vorher klären. Eine simulierte Architektur ist kein gleichwertiger Nachweis für native Bibliotheken oder plattformspezifische Artefakte.

Erster Tag: Paket- und Ergebnisregression

Am ersten Tag geht es nicht darum, möglichst viele Pakete zu installieren. Entscheidend sind die Abhängigkeiten, die Ihre Forschungsfrage, Ihre Abbildungen oder Ihre veröffentlichte Methode tragen.

Paketprüfung mit Priorität

Erstellen Sie eine kurze Testliste mit diesen Gruppen:

  • direkt verwendete Kernpakete für Modelle, Statistik, Optimierung oder Datenverarbeitung;
  • Pakete für Import und Export der im Projekt verwendeten Formate;
  • Pakete für Visualisierung und Berichtserzeugung;
  • native oder plattformspezifische Abhängigkeiten;
  • interne Pakete Ihrer Arbeitsgruppe.

Starten Sie mit einem Importtest und gehen Sie dann zu einem Minimalbeispiel über. Danach führen Sie den realen repräsentativen Lauf aus. Ein Paket, das sich importieren lässt, kann bei einer bestimmten Eingabe, einem seltenen Datentyp oder einem Exportpfad trotzdem versagen. Notieren Sie für jeden Fehler die kleinste reproduzierbare Eingabe, statt nur einen langen Terminalauszug zu speichern.

Die Dokumentation zur Paketverwaltung ist für das Wiederherstellen, Aktualisieren und Festhalten einer Umgebung maßgeblich. Prüfen Sie insbesondere, ob eine Änderung nur in der neuen Testumgebung auftritt oder ob Ihr bisheriges Manifest ebenfalls betroffen ist.

Numerische Regression statt Starttest

Ein numerischer Regressionstest muss fachlich interpretierbar sein. Vergleichen Sie mindestens:

  • zentrale Tabellenwerte und Einheiten;
  • ausgewählte Grafiken einschließlich Achsen, Skalierung und Legenden;
  • Konvergenzverlauf, Iterationsabbruch und Warnungen;
  • Modellparameter, Residuen oder Fehlerschätzer, soweit sie für Ihre Arbeit relevant sind;
  • erzeugte Dateien und deren nachgelagerte Verarbeitung.

Definieren Sie die Toleranz vor dem Vergleich. Für jede Größe kann eine andere Grenze sinnvoll sein; eine pauschale Aussage wie „die Werte sind fast gleich“ ist für eine Dissertation oder ein veröffentlichtes Verfahren nicht ausreichend. Kleine Abweichungen können aus Rundung oder paralleler Ausführung entstehen, größere Abweichungen verlangen eine Ursachenanalyse.

Wiederholen Sie einen auffälligen Lauf mit denselben Eingaben und dokumentieren Sie, ob die Abweichung deterministisch ist. Prüfen Sie anschließend Zufallsquellen, Threads, Solveroptionen, Paketversionen und Plattformunterschiede. Solange die Ursache nicht verstanden ist, sollte die produktive Pipeline auf dem gesicherten alten Stand bleiben.

Erste Woche: CI, Dokumentation und Übergabe

In der restlichen ersten Woche wird aus einem persönlichen Test eine belastbare Gruppenentscheidung. Viele Upgradeprobleme entstehen nicht im Hauptskript, sondern in Automatisierung und Übergabe.

CI-Matrix

Fügen Sie Julia 1.13 zunächst als zusätzliche Testspur hinzu, nicht als sofortigen Ersatz für die bisherige Version. Prüfen Sie:

  • Wird die gewünschte Julia-Version tatsächlich installiert?
  • Wird die richtige Projektumgebung aktiviert?
  • Werden Artefakte und Cache-Einträge getrennt behandelt?
  • Läuft der Test auf jeder vorgesehenen Plattform?
  • Sind Warnungen sichtbar, oder werden sie nur im Log versteckt?
  • Kann ein fehlgeschlagener Lauf eindeutig der Julia-, Paket- oder Betriebssystemversion zugeordnet werden?

Für GitHub Actions beschreibt die offizielle Dokumentation zu Job-Variationen, wie mehrere Varianten eines Jobs ausgeführt werden können. Für Julia-Projekte kann außerdem die Dokumentation von setup-julia bei der Einrichtung der Version helfen. Diese Quellen zeigen den Mechanismus, ersetzen aber nicht Ihre Entscheidung über Testfälle und Freigabekriterien.

Dokumentationsprüfung

Suchen Sie in README-Dateien, Installationsanleitungen, Skripten und Lehrmaterialien nach fest eingetragenen Versionsannahmen. Aktualisieren Sie nicht nur die sichtbare Versionsnummer. Ein neuer Installationsbefehl, ein anderer Pfad oder eine zusätzliche native Abhängigkeit muss für eine neue Person nachvollziehbar sein.

Eine gute Übergabe beschreibt:

  • welche Julia-Version für reproduzierte Ergebnisse verwendet wurde;
  • welche Version für neue Entwicklung getestet wird;
  • wie die alte Umgebung aktiviert wird;
  • welche Pakete derzeit gesperrt oder gepatcht sind;
  • welche Tests vor einem Merge erfolgreich sein müssen;
  • wer die nächste Prüfung übernimmt und wann sie stattfindet.

Wenn mehrere Personen remote oder auf unterschiedlichen Betriebssystemen arbeiten, führen Sie einen Wiederherstellungstest mit einem frischen Benutzerkonto oder einer möglichst unberührten Testumgebung durch. Dabei zeigt sich, ob die Dokumentation tatsächlich genügt oder ob Ihr eigener Rechner stillschweigend lokale Voraussetzungen beisteuert. Für die technische Dokumentation sollten Sie festhalten, wie Zugänge, Sitzungen, Datenablage und Löschung geregelt sind; diese Punkte gehören in die institutsinterne Betriebsanweisung und nicht nur in ein persönliches README.

Langfristige Entscheidung und Rückfall

Nach der ersten Woche sollte Ihre Arbeitsgruppe eine schriftliche Entscheidung treffen. „Funktioniert bei mir“ ist kein ausreichendes Freigabekriterium, wenn andere Mitglieder dieselbe Umgebung für Publikationen, Lehrveranstaltungen oder automatisierte Auswertungen benötigen.

Upgrade ist vertretbar, wenn Kernpakete reproduzierbar aufgelöst werden, die fachlich relevanten Ergebnisse innerhalb vorab begründeter Toleranzen liegen, CI/CD erfolgreich läuft und die alte Umgebung archiviert bleibt.

Parallelbetrieb ist sinnvoll, wenn Julia 1.13 für neue Entwicklung geeignet erscheint, aber einzelne Pakete, native Abhängigkeiten oder Drittanbieterprozesse noch nicht abschließend bewertet sind. Kennzeichnen Sie dann in jedem Ergebnis, mit welcher Julia-Version es entstanden ist.

Aufschub ist die richtige Entscheidung, wenn zentrale Resultate abweichen, ein notwendiges Paket keine belastbare Kompatibilitätsaussage besitzt oder die Wiederherstellung nicht getestet wurde. Ein Aufschub ist kein Scheitern, sondern eine kontrollierte Begrenzung des Reproduzierbarkeitsrisikos.

Für die längerfristige Wartung sollten Sie einen nächsten Prüftermin, eine verantwortliche Person und einen Auslöser für eine außerplanmäßige Prüfung festlegen. Solche Auslöser können ein Paketrelease, eine dokumentierte Regression, eine Änderung der Hochschulinfrastruktur oder ein bevorstehender Abgabetermin sein. Die Entscheidung zwischen Stable und LTS sollte nicht pauschal erfolgen: Ein neues Projekt mit kurzer Entwicklungsphase kann anders priorisieren als eine mehrjährige Mess- oder Simulationspipeline. Eine getrennte Anleitung zur Auswahl zwischen Julia Stable und LTS auf dem Mac sollte deshalb als Folgeentscheidung gelesen werden, nicht als Ersatz für die Projekttests.

Ergebnis der ersten Woche

Am Ende sollten fünf Dinge auffindbar sein: der eingefrorene alte Stand, die getrennte Julia-1.13-Umgebung, ein Protokoll der Paket- und Ergebnisregression, der CI-Nachweis sowie eine begründete Entscheidung mit Rückfallweg. Fehlt eines davon, ist die technische Bewertung noch nicht abgeschlossen.

Wenn Ihr bisheriger Ansatz ein gemeinsam genutzter Linux- oder Windows-Rechner ohne Apple-Silicon-Zugang ist, bleiben zudem konkrete Nachteile: Sie können native macOS-Abhängigkeiten nicht real prüfen, Architekturfehler erst spät erkennen und teilen sich möglicherweise eine Umgebung mit unklaren Versionsänderungen. Für einen zeitlich begrenzten Validierungslauf kann eine gemietete echte Mac-Umgebung deshalb die sauberere Ergänzung sein: Sie behalten Ihre bestehende Forschungsinfrastruktur, erhalten aber einen getrennten Prüfpfad für macOS und Apple Silicon. Das ist vor allem dann sinnvoll, wenn Sie nur für Kompatibilität, CI oder eine Abnahme testen müssen; für dauerhaft hohe Last, spezielle Laborhardware oder eine langfristig konstante Rechenumgebung ist eine eigene, institutionell verwaltete Lösung weiterhin zu prüfen.

Häufige Fragen

Die folgenden Antworten fassen die wichtigsten Entscheidungen zusammen, ohne die Prüfung Ihrer konkreten Pakete und Referenzergebnisse zu ersetzen.

Julia 1.13 nach der Veröffentlichung: Soll ein altes Projekt sofort aktualisiert werden?

Nein. Sichern Sie zuerst Julia-Version, Projektdateien, Manifest, CI-Konfiguration und Referenzergebnisse. Danach prüfen Sie Julia 1.13 in einer getrennten Umgebung. Ein sofortiger Austausch ist nur dann vertretbar, wenn Paketauflösung, numerische Regression, CI und Wiederherstellung bereits nachvollziehbar getestet wurden. Bei ungeklärten Abweichungen bleibt das alte Projekt produktiv.

Wie prüfen Sie die Kompatibilität wissenschaftlicher Julia-Pakete mit Julia 1.13?

Priorisieren Sie die Pakete, die Ihre Modelle, Datenformate, Exporte und Abbildungen tragen. Testen Sie zuerst Import und Minimalbeispiel, danach den repräsentativen Forschungsworkflow. Prüfen Sie Project.toml, Manifest.toml, Kompatibilitätseinträge und native Abhängigkeiten. Ein erfolgreicher Paketimport genügt nicht, wenn spätere Daten- oder Exportpfade noch fehlschlagen.

Wie verifizieren Sie unveränderte numerische Ergebnisse nach einer neuen Julia-Version?

Legen Sie vor dem Upgrade Referenztabellen, Grafiken, Parameter, Konvergenzprotokolle und relevante Fehlerschätzer ab. Definieren Sie fachlich begründete Toleranzen und wiederholen Sie auffällige Läufe mit denselben Eingaben. Trennen Sie Rundungs- und Zufallseffekte von echten Modelländerungen. Ungeklärte Abweichungen sind ein Grund für Parallelbetrieb oder Aufschub.

Wie testen Sie Julia 1.13 unter Apple Silicon ohne eigenen Mac?

Verwenden Sie eine tatsächlich erreichbare Apple-Silicon-Umgebung und prüfen Sie dort Installationsquelle, Architektur, Paketwiederherstellung, native Abhängigkeiten und repräsentative Regressionen. Eine Intel- oder Linux-Umgebung kann diesen Nachweis nicht vollständig ersetzen. Vor dem Fernzugriff müssen Sie Datenklassifizierung, Zugriffsrechte, Löschung und institutionelle Datenschutzanforderungen klären.

Julia 1.13 nach der Veröffentlichung für Forschungsprojekte ist damit kein reines Installationsereignis, sondern ein kontrollierter Prüfprozess: erst einfrieren, dann isoliert testen, anschließend Ergebnisse und Automatisierung bewerten und erst danach die Versionsstrategie freigeben. Wenn Sie dafür vorübergehend eine echte Apple-Silicon-Umgebung benötigen, sollten Sie den Test ausdrücklich als begrenzte Validierung mit dokumentiertem Rückfall planen.