Versionierung - Garados007/IlarosLauncher GitHub Wiki

Allgemeines

Das komplette Paket besteht aus verschiedenen Komponenten, die alle verschiedene Versionsnummern haben. Dazu kommen noch eine Menge von Ressourcendateien, die sich nicht mit einer Versionsnummer beschreiben lassen. Von daher gibt es für die Updatesysteme eigene Versionierungsmechanismen:

Jedes Serversystem verwaltet seine eigene Versionshistorie. Zu jeder Versionsnummer werden die Versionsnummern jeder Assembly (exe oder dll Dateien) und Hashes jeder Ressourcendatei zusammengefasst. Sollte sich eine Versionsnummer einer Abhängigkeit ändern, so wird die Paketversionsnummer inkrementiert. Zusätzlich werden zu jeder Paket-Versionsnummer alle geänderten Abhängigkeiten gemerkt. So kann der Launcher immer erfahren, wann sich welche Abhängigkeit geändert hat. So wird der Download immer minimal gehalten.

Die Serversysteme speichern aber immer nur die Dateien der neusten Version. Ein Zurückspringen zu alten Versionen ist also nicht möglich.

Zu jeder Paket-Versionsnummer gibt es eine eigene JSON-Datei im Versionsordner des Serversystems. Der Name orientiert sich immer nach dem Muster Versionsnummer.json. Eine Datei sieht dann so aus:

{
  "version": "1.0.27",
  "date": 1290129102912,
  "modules": [
    {
      "path": "/Client/IlarosLauncher.exe",
      "version": "1.89.3",
      "name": "IlarosLauncher.exe"
    }
  ],
  "ressources": [
    {
      "path": "/ClientContent/web/css/styles.css",
      "hash": "ae165165131fb643561",
      "name": "styles.css"
    }
  ],
  "deleted": [
    {
      "path": "/ClientContent/web/css/allstyles.css",
      "name": "allstyles.css"
    }
  ]
}

Zusätzlich existiert eine Datei current.json, welche nicht nur die aktuelle Versionsnummer enthält, sondern die Informationen aller Abhängigkeiten. Sie ist nach dem gleichem Schema wie oben aufgebaut, nur entspricht das Datum nicht dem Erstelldatum, sondern der letzten Überprüfung.

Abruf nach Updates

Wenn der Launcher nach Updates anfragt, dann geschieht intern folgendes:

  1. Server schaut nach, wann er zuletzt nach Versionsänderungen gesucht hatte. Ist es weniger als 1 Stunde her, dann weiter mit Punkt 3.
  2. Server überprüft alle Dateien ob sie noch aktuell sind, wenn nicht, dann erstellt er eine Versionsnummer und schiebt alle Änderungen dort rein.
  3. Der Launcher bekommt die aktuelle Versionsnummer und überprüft seine eigene Aktualität.

Wenn der Updater nun alle geänderten Dateien bekommen will, so geschieht folgendes:

  1. Updater schickt seine eigene Versionsnummer dem Server.
  2. Der Server geht ab dieser Versionsnummer alle folgenden bis zur aktuellen durch und merkt sich alle geänderten Dateien.
  3. Der Server gibt eine JSON Liste zurück, die nach dem gleichem Schema wie oben aufgebaut ist.
  4. Updater ruft nun all diese Dateien ab und aktualisiert seinen eigenen Stand.

Wenn eine Neuinstallierung vorliegt, so wird keine Versionsnummer übertragen und man erhält eine Liste aller Dateien.

Hinweis an den Serverbetreiber: Will man ein Versionsaktualisierung erzwingen und nicht eine Stunde warten, so muss man einfach bei der current.json das date Feld auf 0 setzen.

Aufbau der Versionsnummer

Hauptversion.Unterversion.Revision

Optional steht bei Modulen noch hinten dran die Buildnummer. Bei einem automatischen Versionswechsel des Servers wird nur die Revisionsnummer um 1 erhöht. Will man größere Änderungen oder sogar große Versionswechsel darstellen, so ist dies manuell zu geschehen (einfach in current.json die Versionsnummer ändern).