Update-Instruktionen in der Package.XML --> hier: Updater-Versionsbereich definieren

  • App
    WoltLab Suite Core

    In der Package.xml wird ja unter anderem auch ein Update-Tag verwendet.

    Derzeit gibt es leider aber nur eine Updatemöglichkeit entweder für die ganze Versionsreihe wie zum Beispiel: <update fromversion="3.0.*"> oder halt nur von einer expliziten Version wie zum Beispiel <update fromversion="3.0.11">

    Das einzige Problem an diesem Vorgehen ist die fehlende Einschränkung einer Mindestversion, ein 3.0.* trifft halt auf jede 3.0er Version zu und man kann aktuell nicht festlegen, dass man z. B. nur >= 3.0.12 abdecken möchte.

    Somit würde ich gerne die Möglichkeit haben wollen, ein generelles Update für einen Versionsbereich angeben zu können:

    Wie zum Beispiel

    <update fromversion="3.0.11" maxversion="3.0.16">

    Hier sollten dann alle Versionen von 3.0.11 bis 3.0.16 in diesem Tag updatebar sein...

    Das fehlt mir noch in der Update-Routine....


    Diesen Vorschlag würde ich auch gerne dann im WSC3.0 und auch im WCF2.1 inne haben wollen!

  • Und was ist, wenn ich dann ab Version 3.0.16 bis Version 3.0.18 eine minimierte Update-Instruktion haben möchte?

    Beispiel:

    Das geht dann nicht...

  • Das geht doch, indem du 3.0.16 auf Exclude setzt und 3.0.11 als minversion.

    Aber damit gehen dann nicht unterschiedliche Update-Anweisungen für verschiedene Versionsbereiche.

    Code
    <update fromversion="3.0.11" maxversion="3.0.16">
        <do this>
    <update fromversion="3.0.17" maxversion="3.0.20">
        <do that>
    <update fromversion="3.0.21">
        <do other>

    wobei ich vom Syntax her als Äquivalent zu fromversion dann eher toversion oder untilversion logisch finden würde. maxversion hat gefühlt was von endgültig, weil es nur ein Maximum gibt.

    ________________________________________________________________
    WSC-Support - Code & Design für die WoltLab Suite

    3DCommunity - https://www.3d-board.de

    Einmal editiert, zuletzt von djblueprint (6. März 2018 um 09:44)

  • wobei ich vom Syntax her als Äquivalent zu fromversion dann eher toversion oder untilversion logisch finden würde. maxversion hat gefühlt was von endgültig, weil es nur ein Maximun gibt.

    Ja... das stimmt... der Name wäre noch anpassbar...

  • Marcel Werk 2. März 2020 um 17:03

    Hat das Label Nicht geplant hinzugefügt.
  • Schade, dass so etwas nicht eingebunden wird...

    Aber man kann es ja auch einfach alles in die kleine Update-Anweisung hineinpacken, was auch in der größeren Version zum Update auch benötigt wird...

  • Naja, das WSC empfiehlt halt die inkrementellen updates über alle zwischen Versionen, der von dir vorgeschlagene Weg wäre eine Monolithische Update-Anweisung für zig versionen.

    Das ist deutlich fehler anfälliger und mit Paketservern sollte es kein Problem sein für einen Admin alle Zwischenversionen schrittweise zu installieren.

  • Naja, das WSC empfiehlt halt die inkrementellen updates über alle zwischen Versionen, der von dir vorgeschlagene Weg wäre eine Monolithische Update-Anweisung für zig versionen.

    Das ist deutlich fehler anfälliger und mit Paketservern sollte es kein Problem sein für einen Admin alle Zwischenversionen schrittweise zu installieren.

    Ähm, das widerspricht sich damit, denn das geht bereits heute schon:

    Derzeit gibt es leider aber nur eine Updatemöglichkeit entweder für die ganze Versionsreihe wie zum Beispiel: <update fromversion="3.0.*">

    In der Tat ging das früher schon. Wenn ich mich recht entsinne sogar schon in WCF 1.0, da bin ich mir jedoch nicht zu 100% sicher. Die Angabe einer maximalen und minimalen Version wäre hier nur konsequent. Schade, dass dies scheinbar nicht gewünscht ist.

    PS: Ich hätte schon irendwie Lust einen Wunsch einzureichen, Reaktionen auch auf "Labelwechseln" zuzulassen. :D

    MfG Markus Zhang (aka RouL)

  • Ähm, das widerspricht sich damit, denn das geht bereits heute schon:

    Gehen tut es durchaus, wird aber im allgemeinen nicht für normale Updates verwendet sondern vor allem für Upgrades von älteren Versions-Zweigen die selbst weiter gepflegt werden.

    In den meisten Fällen ist es eh irrelevant, da man die meisten PIPs ohne wirkliche Nachteile einfach neu durchlaufen lassen kann, Ausnahmen stellen hier die script-pip (bedingt, kann der entwickler natürlich durchaus einkalkulieren) und die sql-pip dar.

    Ich persönlich sehe ehrlich gesagt keinen wirklichen Nutzen darin und eine komplexere und somit anfälligere Logik für das suchen des passenden Update Pfades bei Verwendung der Paketserver. Ich kann also durchaus verstehen weshalb WoltLab hier die Zeit nicht investieren will, insbesondere da es bei Updates über Paketserver gar nicht notwendig ist und die aller meisten User genau so vorgehen.

  • Ja... stimmt auch irgendwie... man kann ja einfach in jeder Version nur die vorherige als Update zulassen. Dann ist die Änderung zwischen mehreren Versionen auch möglich, nur mit dem Unterschied, dass das WSC dann von zum Beispiel Version 3.0.2 erst auf 3.0.3 updatet, dann erst von 3.0.3 auf die 3.0.4 und dann erst von 3.0.4 auf die 3.0.5. Statt direkt von der 3.0.2 zur Version 3.0.5 in einem Zug...

  • Ja... stimmt auch irgendwie... man kann ja einfach in jeder Version nur die vorherige als Update zulassen. Dann ist die Änderung zwischen mehreren Versionen auch möglich, nur mit dem Unterschied, dass das WSC dann von zum Beispiel Version 3.0.2 erst auf 3.0.3 updatet, dann erst von 3.0.3 auf die 3.0.4 und dann erst von 3.0.4 auf die 3.0.5. Statt direkt von der 3.0.2 zur Version 3.0.5 in einem Zug...

    Exakt und das ist gerade für den Anwender eher störend um das mal ganz freundlich auszudrücken. Ich habe das mit dem schon damals häufig verwendet um Benutzern solche Versionssprünge zu ermöglichen. Wenn jetzt aber mal SQL oder Skripte dabei sind oder andere PIPs verwendet werden, welche nicht mehrfach ausgeführt werden dürfen, wäre es echt praktisch. Vergiss an der Stelle übrigens nicht, dass WoltLab nicht die einzigen sind, welche PIPs schreiben, bevor du mir mitteilst, dass es ja nur die 2 gibt, bei welchen das zutrifft ( Morik).

    MfG Markus Zhang (aka RouL)

    Einmal editiert, zuletzt von Markus Zhang (3. März 2020 um 13:16) aus folgendem Grund: Zitat und Namensnennung eingefügt.

  • Wenn man mit Paketservern arbeitet, fällt dem normalen Benutzer das aber doch gar nicht erst auf, oder doch?
    Den das System bei einem Update sollte doch genau das automatisch machen.

    Du meinst bei einem Update alle Zwischenschritte nacheinander durchführen ohne weitere Benutzerinteraktion?

    MfG Markus Zhang (aka RouL)

  • Das kann ich dir gerade leider nicht sagen, so tief habe ich mich noch nicht wieder eingearbeitet. Aber es ist halt nicht zwangsläufig notwendig, nur weil es geht. Schneller geht es, wenn der jeweilige Entwickler bereits alles nötige in ein Paket integriert. Sicher macht das nicht jeder, aber es spart Schritte im Updateprozess und damit ist das update dann schneller durch. In der Regel ist das im Sinne des Forenbetreibers. Zudem ist dies weniger fehleranfällig, wenn der Entwickler weiß was er macht und anständig testet.

    Machen wir mal absichtlich ein extremes und ggf. leicht unrealistisches Beispiel: Schauen wir mal das WSF 5.1 an. Stelle dir mal vor du hast die 5.1.0 installiert und möchtest auf die aktuelle 5.1 updaten. Das sind dann halt mal 11 Updates alleine für das eine Paket. Dazu kommen noch Abhängigkeiten. Jetzt stell dir vor es wäre möglich das alles mit einem Update pro Paket machen zu können und das ohne, dass er auch alle PIPs ausführt, die er nicht ausführen muss. ;)

    MfG Markus Zhang (aka RouL)

  • Moin Ihr!

    Blöd wird es erst bei Upgrades bzw. mehreren Versionssträngen.

    Na, blöd ist das nicht. Man muss halt nur schauen, dass der Sprung von 3.0 auf 3.1 (zum Beispiel) in nur einer Version passiert. Und dann halt erstmal die 3.0 auf die aktuellste Version geupdatet werden muss, bevor dann der Sprung auf die 3.1 passieren kann. Ist aber so kein Problem...

    Exakt und das ist gerade für den Anwender eher störend um das mal ganz freundlich auszudrücken.

    Wieso soll das störend sein, wenn das WSC die Updates der Reihe nach automatisch durchführt?

    Wenn man mit Paketservern arbeitet, fällt dem normalen Benutzer das aber doch gar nicht erst auf, oder doch?
    Den das System bei einem Update sollte doch genau das automatisch machen.

    Das ist korrekt, das System wird ohne einen Handgriff vom Benutzer schön nach einander jede Version aktualisieren, bis die neuste Version am Ende vorhanden ist.

    Machen wir mal absichtlich ein extremes und ggf. leicht unrealistisches Beispiel: Schauen wir mal das WSF 5.1 an. Stelle dir mal vor du hast die 5.1.0 installiert und möchtest auf die aktuelle 5.1 updaten. Das sind dann halt mal 11 Updates alleine für das eine Paket. Dazu kommen noch Abhängigkeiten. Jetzt stell dir vor es wäre möglich das alles mit einem Update pro Paket machen zu können und das ohne, dass er auch alle PIPs ausführt, die er nicht ausführen muss.

    Ja das macht doch nichts. Wie oben schon geschrieben, wird das System jede Version von 5.1.0 über 5.1.1, dann 5.1.2 und dann 5.1.3 usw. nach einander Installieren.

    Das ist in meinen Augen auch sinnvoll, denn so hat man nicht die Schwierigkeit irgendwelche Scripte sich dann anzuschauen und neu schreiben zu müssen, die dann Sprünge erlauben.

    Als Beispiel:

    Update von 5.1.0 auf 5.1.1:

    Ein Script soll beim Update von Version 5.1.0 auf 5.1.1 den Code in von Buchstabe A nach Buchstabe B ändern.

    Update von 5.1.1 auf 5.1.2:

    Ein Script soll beim Update von Version 5.1.1 auf 5.1.2 den Code in von Buchstabe B nach Buchstabe C ändern.

    Update von 5.1.2 auf 5.1.3:

    Ein Script soll beim Update von Version 5.1.2 auf 5.1.3 den Code in von Buchstabe C nach Buchstabe D ändern.


    Damit haben wir jetzt schon dann bei einem Sprung von 5.1.0 auf 5.1.3 nur ein Script mit der Anweisung: Buchstabe A nach Buchstabe D.

    ABER: von 5.1.1 auf 5.1.3 wäre die Anweisung: Buchstabe B nach Buchstabe D.

    UND: von 5.1.2 auf 5.1.3 wäre die Anweisung: Buchstabe C nach Buchstabe D.

    Damit wären statt einem Script schon 3 Scripte nötig, die dann entsprechend der momentanen Version aufgerufen werden müssen.

    Man könnte zwar sagen, sofern es möglich ist, Ändere egal welchen Buchstaben nach D. Dann hätte man wieder nur ein Script. Aber manchmal geht es einfach nicht.

    Und das ist nur ein kleiner Änderungs-Weg. Wenn man Scripte oder andere Pips einsetze, die an der Datenbank-Struktur arbeiten, ist ein Sprung über mehrere Versionen mit mehreren Änderungen immer sehr schwer. Man muss echt auf jede Kleinigkeit achten, damit am Ende der Update-Routine die alte Version genauso aussieht, wie die neue Version frisch installiert. Da ist die Kunst dabei.

    Und darum würde ich immer, gerade bei schweren Änderungen an DB oder anderen Datei-Strukturen, jeden Versionssprung einzeln zu machen und nicht von 5.1.0 auf z.B. 5.1.3 zu springen.

    Dann geschehen auch keine Fehler...

    Gruß

    Markus

  • Wieso soll das störend sein, wenn das WSC die Updates der Reihe nach automatisch durchführt?

    Ok, das kam ggf. falsch rüber. Ich finde es ist störend wenn immer eine ganze Reihe an Updates eines Paketes durchgeführt werden muss anstatt einfach ein Update für das jeweilige Paket durchzuführen. Das falls mehrere notwendig sind alle in in einer Reihe ohne weitere Benutzerinteraktion installiert werden ist selbstverständlich erfreulich.

    Bei schweren Änderungen, wie du geschrieben hast macht es ja auch ggf. Sinn, bzw bei umfangreichen Änderungen an den Daten an der selben Stelle. Das ist ja aber eher die Ausnahme. Und da macht es dann halt Sinn ggf. wie du geschrieben hast für Update-Instruktionen Versions-Bereiche festlegen zu können um dem Benutzer ein ich sage mal "11 Schritt Update" zu ersparen, wenn dieses nicht notwendig ist. Ggf. lässt sich das mit den passenden Updateanweisungen auf 2-3 Schritte runterbrechen. So hatte ich dich zumindest verstanden. Zumal so auch eventuelle Wartungsphasen in Foren klein gehalten werden können.

    MfG Markus Zhang (aka RouL)

  • Ich finde es ist störend wenn immer eine ganze Reihe an Updates eines Paketes durchgeführt werden muss anstatt einfach ein Update für das jeweilige Paket durchzuführen. Das falls mehrere notwendig sind alle in in einer Reihe ohne weitere Benutzerinteraktion installiert werden ist selbstverständlich erfreulich.

    Was genau ist daran störend wenn ich fragen darf?

    Die meisten update schritte erfolgen in einem einzigen request der vll 100ms benötigt (es können ja viele PIPs in einem Rutsch abgearbeitet werden), wenn er dann 10 zwischenscritten machst sind das also eventuell 1 sekunde die das Update länger benötigt.

    Das ist in meinen Augen kein störendes Problem da es den meisten Admins nicht mal auffällt und wer sein System so lange nicht Updatet dass er derart viele Updates benötigt um auf den aktuellen Stand zu kommen hat am ende eh ganz andere Probleme.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!