Wie macht man ein Update von 4.0.8 auf 4.0.9 oder gleich auf 4.0.10?

[cjs1976]

Hallo!

Ich setze OTRS Free in Version 4.0.8 ein, und würde gerne auf 4.0.9 (oder 4.0.10) updaten. Leider finde ich dazu nirgendwo einen Anleitung.

Kann mir bitte jemand sagen, wie man so ein Update durchführt?

Danke,
Christian.

[RStraub]

Die UPGRADING.md verweist dich auf:
http://otrs.github.io/doc/manual/admin/ ... ading.html

[cjs1976]

Oh, ich dachte da geht es nur um das Upgrade von 3.3 auf 4.

Leider macht mir das FAQ-Modul ein paar Probleme. Weiß jemand Rat?

Nachtrag/Lösung: Obwohl sich die Version des FAQ-Moduls nicht geändert hatte, musste ich es neu installieren. Danach hat alles einwandfrei geklappt.

Danke,
Christian.

[RStraub]

Das beschreibt auch Minor-Updates und sagt dir welche Schritte du dazu auslassen kannst.

Rat haben wir sicher, was genau ist das Problem ?

[Ebebalf]

Die UPGRADING.md verweist dich auf:
http://otrs.github.io/doc/manual/admin/ ... ading.html

Wie kommt es eigentlich, dass man da so ziemlich jede Minor-Version mitnehmen muss? Also was ist da der genaue Grund?
Sollte es nicht grundsätzlich reichen, irgendwie die Datenbank vom jeweils alten Format in das aktuelle zu übertragen?

Mal so als Beispiel: Angenommen man wollte OTRS 2.0.x aufs aktuelle 4.0.10 bekommen, dann muss man der Anleitung zufolge ja neun Zwischenversionen installieren. Dabei ist es doch letztenendes nur die Datenbank, die angepasst werden muss. (Alle anderen Einstellungen, also die in den Konfig-Dateien, kann man doch neu machen).

[jojo]

Hallo,

es ist deutlich mehr als nur ein Datenbank Upgrade wie Du den einzelnen Perl Upgrade Scripten entnehmen kannst.

Ein Update z.B. von einer 2.0.3 würde wie folgt aussehen:


2.0.3 -> 2.1.latest
2.1.latest -> 2.2.latest
2.2.latest -> 2.3.latest
2.3.latest -> 2.4.latest
2.4.latest -> 3.0.latest
3.0.latest -> 3.1.latest
3.1.latest -> 3.2.latest
3.2.latest -> 3.3.latest
3.3.latest -> OTRS4 (latest)

Bei frühen Versionen (inkl. 2.4) kannst Du direkt auf die jeweilige Zielversion gehen, da alle Migrationsscripte lauffähig sind. Trotzdem müssen sie ausgeführt werden.

[Ebebalf]

es ist deutlich mehr als nur ein Datenbank Upgrade wie Du den einzelnen Perl Upgrade Scripten entnehmen kannst.

Perl zählt m.E. leider nicht zu den Sprachen, die einfach zu verstehen sind.
Ich betrachte das ganze jedoch aus einer situationsbezogenen Perspektive: Die Skripte und Dateien werden ja bei jeder neuen Version überschrieben. Das einzige was nach dem Update letztlich Bestand hat ist also die Datenbank.

[jojo]

Es gibt jeweils ein Perl basiertes Upgrade Script (das auf die Backened API der jeweiligen Version zurückgreift). Dieses macht einige ANassungen die nicht über ein SQL Script gemacht werden können. Dieses Script muss bei jedem Update durchgeführt werden, siehe oben

[steste123]

Hallo jojo,
wie es eigtl. bei "einfachen" Patchleveln?
Zum Beispiel habe ich aktuell Version 4.0.3 und wenn ich auf die bald kommende OTRS 5 (stable) upgraden möchte, muss ich dann auch erst auf das letzte Patchlevel (4.0.11) updaten und dann auf OTRS 5 oder kann ich direkt von 4.0.3 auf 5?

[jojo]

Technisch solltest Du direkt auf die 5 können.

Aber es ist grundsätzlich empfehlenswert die Patchlevel upzudaten, da Bugs und auch Security Issues gefixt werden.

[steste123]

Alles klar - beinhalten die neusten Patchlevel die vorherigen?
Also wenn ich auf Patchlevel 11 update sind da auch 10,9,8,.... enthalten?

[jojo]

ja

[Ebebalf]

Es gibt jeweils ein Perl basiertes Upgrade Script (das auf die Backened API der jeweiligen Version zurückgreift). Dieses macht einige ANassungen die nicht über ein SQL Script gemacht werden können. Dieses Script muss bei jedem Update durchgeführt werden, siehe oben

Das Anpassungen nötig sind, die nicht über SQL selbst machbar sind ist mir schon absolut klar.
Was ich nicht verstehe ist, wieso es nicht möglich sein soll ein Skript mitzuliefern, was eben die Datenbank einer 2.0.x oder einer 3.1.x Version direkt und ohne Zwischenschritte auf die jeweils aktuelle Version konvertiert.

Dieses Vorgehen von „nächst-höhere Minor-Version installieren – Skript ausführen – testen ob alles funktioniert – gehe zum Anfang“ mehrfach auszuführen kostet ja nicht nur unnötig Zeit, sondern ist darüber hinaus nicht unbedingt Benutzerfreundlich (bzw. in dem Fall eher „Adminfreundlich“ ).

[jojo]

Das Script greift auf die API der jeweiligen Version zurück, diese ändert sich jedoch regelmäßig. D.h. in neueren Versionen der API sind ggf. Funktionen nicht mehr drin die bei einer früheren Version für eine Migration notwendig waren.

Die Pflege (und das Testen) alter Migrationen ist absolut unnötiger Entwicklungsaufwand.

Wenn der Admin regelmäßig updated stellt sich die Frage sowieso nicht.