Start / Artikel / Updates und Supersedence

Upgrade

Updates und Supersedence als Betriebsmodell verstehen.

Ein Paket ist nicht fertig, wenn Version 1 installiert. Wirklich belastbar wird es erst, wenn Upgrade, Ersetzung, Rollback und Detection ueber mehrere Versionen sauber funktionieren.

Update

Das bestehende Produkt bleibt logisch erhalten und wird auf einen neuen Stand gebracht. Detection und Benutzerdaten muessen danach weiterhin passen.

Supersedence

Ein neues Paket ersetzt ein altes Paket im Deployment-System. Das ist mehr als nur eine neue Version: Reihenfolge, Deinstallation und Zuordnung werden aktiv gesteuert.

Side-by-Side

Nicht jede neue Version ersetzt die alte. Manche Hersteller erlauben oder erwarten parallele Installationen. Dann ist eine falsche Supersedence-Logik selbst der Fehler.

Rollback

Wenn ein Upgrade fehlschlaegt, muss klar sein, welcher Zustand danach erwartet wird: alte Version, keine Version oder halb migrierter Mischzustand.

Praxisfragen

Was vor jedem Versionswechsel beantwortet sein muss

Die haertesten Fehler zeigen sich oft erst zwischen zwei Versionen, nicht im Erstinstallationslauf.

Ersetzt die neue Version die alte wirklich?

Bei MSI helfen UpgradeCode, Upgrade-Tabelle und ProductCode-Wechsel. Bei EXE-Installern braucht es echte Vorher/Nachher-Tests.

MSI-Upgradecodes lesen

Bleiben Detection und Uninstall stabil?

Wenn Detection hart auf eine Einzelversion gebaut ist, wird ein Major Upgrade spaeter oft als "nicht installiert" fehlinterpretiert.

Detection mit PowerShell lesen

Was passiert mit Benutzerdaten und Plugins?

Upgrade kann Dateien ersetzen, Profile migrieren oder Altlasten liegenlassen. Das gehoert in die Testmatrix.

Testmatrix lesen

Wer deinstalliert Altversionen?

Manche Setups entfernen Vorgaenger selbst, andere brauchen explizite Altversionen-Logik im Deployment.

Uninstall in der Praxis lesen
Upgrade-Check
Mindestens pruefen:
- Altversion A vorhanden, neue Version B wird installiert
- Detection vor und nach dem Upgrade
- Uninstall-String nach dem Upgrade
- Daten, Dienste, Plugins und Scheduled Tasks
- Verhalten bei Reboot oder Fehler im Mittelzustand

MEM / MECM

Worauf Supersedence im Deployment-System angewiesen ist

Supersedence ist nur so sauber wie das Paketdesign darunter.

Klare Detection pro Paketstand

Das neue Paket muss sicher erkannt werden, ohne die Altversion versehentlich weiterhin als gueltig zu betrachten.

Dokumentierte Ersetzungsrichtung

Es muss klar sein, welche Version wen ersetzt und ob dabei eine Deinstallation der Altversion noetig ist.

Abhaengigkeiten und Reihenfolge

Wenn neue Versionen andere Runtimes oder Frameworks brauchen, ist die Supersedence ohne Dependency-Plan unvollstaendig.

Dependencies lesen

Architektur sauber trennen

x86 und x64 derselben App duerfen nicht automatisch dieselbe Supersedence-Logik teilen, wenn Detection und Pfade unterschiedlich sind.

32/64-Bit-Fallen lesen

Typischer Fehler

Ein Paket wird als "neue Version" gebaut, aber Detection, Altversionen-Logik und Uninstall bleiben auf dem alten Stand. Dadurch entstehen Doppelinstallationen oder Wiederangebote.

Trust bleibt relevant

Jede neue Version ist auch eine neue Vertrauensentscheidung: neue Signatur, neuer Publisher-Hash, neue Quelle oder neuer Wrapper.

Security und Trust lesen

Freigabe erst nach Versionswechsel-Test

Ein Erstinstallations-Test ersetzt nie den Upgrade-Test. Beides gehoert in die Freigabe.

Deployment-Checkliste lesen