Versions- und Updateverwaltung

Hallo,

Anwendungen haben eine version, die meist gemäß MajorNumber.MinorNumber.PatchLevel.VersionNumber aufgebaut ist, die aber nicht spezifiziert welche Updates installiert sind. Wie regelt ihr dies, um mehrfaches installieren von Updates zu verhindern?
Hab mir folgendes Schema überlegt:

Versionierung der Anwendung gemäß: MajorNumber.MinorNumber.PatchLevel.VersionNumber
Näheres: siehe Wiki

Versionierung des Updates gemäß: MajorNumber.MinorNumber.UpdateType.VersionNumber

MajorNumber und MinorNumber

• Update muss zur version passen, dies wird anhand der ersten beiden Zahlen festgelegt. Neue Versionen der Anwendung beinhalten dann bereits das Update.

UpdateType gemäß Microsoft Update-Terminologie. Gibt den Typ des Updates an.

• 1 = Sicherheitspatch
• 2 = kritisches Update
  ...
• 8 = Feature Pack

VersionNumber ist eine natürliche Zahl, die inkrementiert wird, die einfach eine ID ist und angibt, was genau behoben wurde.

Wird eine Anwendung mit einem Update aktualisiert, wird die zughörige Update-Versions-Nummer intern gespeichert. Vor einem weiteren Update wird abgeglichen, damit kein downgread oder ein mehrfaches installieren eines Updates erfolgt.

Beispiel: Update 2.3.1.2
2.3 = Update zur Anwendungsversion 2.3
.1 = Ist ein sicherheitspatch
.2 = behebt beispielsweise SQL-Injection

halte ich für sehr undurchsichtig. Eine Update-Versionsnummer sollte im Idealfall der im Update enthaltenen Version entsprechen. So kann man anhand der Programmversion herausfinden, welche Updates einem fehlen. Bei deinem Beispiel könnte zum Beispiel folgendes passieren:

Programmversion 2.3, es kommen mehrere Updates raus.

Zuerst 2.3.1.1, ein Sicherheitspatch. Dann 2.3.2.2, ein kritisches Update. Dann 2.3.8.3, ein Featurepack - und zu guter letzt 2.3.1.4, ein weiterer Sicherheitspatch. Anhand der Nummer kann jemand, der das "übliche" Versionierungsschema gewohnt ist, nicht erkennen, daß der Patch 2.3.1.4 der letzte Patch ist. Und je mehr Patches es gibt, desto verwirrender wird es werden.

Unsere Update-Strategie wurde auch immer komplizierter.

Jetzt schreib ich einfach das Datum des Updates dazu.

Grüße Bernd

Programmversion 2.3, es kommen mehrere Updates raus.

Zuerst 2.3.1.1, ein Sicherheitspatch. Dann 2.3.2.2, ein kritisches Update. Dann 2.3.8.3, ein Featurepack - und zu guter letzt 2.3.1.4, ein weiterer Sicherheitspatch. Anhand der Nummer kann jemand, der das "übliche" Versionierungsschema gewohnt ist, nicht erkennen, daß der Patch 2.3.1.4 der letzte Patch ist. Und je mehr Patches es gibt, desto verwirrender wird es werden.

Zu deinem beispiel:

Es ist eine Programm-Version installiert, beispielsweise: 2.3.1.1 bedeutet
Version 2.3
Patchlevel: 1 (Stand der Fehlerkorrekturen)
Buildnumber: 1 (Kompilierungen)

So, jetzt kommt ein neues kritisches Update heraus: 2.3.2.2
Die Version der Anwendung bleibt gleich, ABER die Updateversion wird intern in der Anwendung gespeichert. Kommt nun ein weiteres neues Update heraus, kann dieses nicht mehr die Version 2.3.2.2 tragen. Die Software vergleicht, ob ob die neue Version bereits installiert wurde mit den intern gespeicherten Versionen. So kann mehrfaches installieren verhindert werden.

warum so aufwändig? Wenn die Update-Versionsnummer höher ist als die Versionsnummer der installierten Anwendung, ist das Update noch nicht installiert. Da muss man sich dann "nur" noch darum kümmern, bei inkrementellen Updates (nur ein Teil der Anwendung enthalten, beispielsweise eine einzelne Bibliothek) nicht eines der Updates auszulassen. Ginge zum Beispiel über eine Prüfung in der Updateroutine, die eine bestimmte Vorversion voraussetzt.

...die eine bestimmte Vorversion voraussetzt.

Genau das ist das Problem, der Kunde kann Updates auslasten, was er auch durchaus macht. In dem Fall muss ich dann irgendwo speichern, welche Updates bereits installiert wurden.

auslasten

Du meinstest auslassen, oder? 🙂

Sowas macht man nicht über die Versionsnummer. Schau dir einfach ab, wie MS das macht. Die Versionsnummern unterscheiden sich nur bei Major oder Minor Releases (RTM, SP1, SP2, usw...). Alles weitere sind Hotfixes, die keine Versionsnummer tragen. Hier müssen nur die Hotfixes wissen, ab welcher Major/Minor Version sie sich installieren dürfen, und ab welcher Major/Minor-Version sie bereits integriert sind. Ebenfalls müssen diese wissen, ob sie in Abhängigkeit zu anderen Hotfixes stehen.

All diese Infos landen zum Schluss in einer Versionsdatenbank (Text, XML, DBMS, egal). IMHO ist das rein über die Versionsnummer nicht realisierbar.

Sonst bekommt man doch ehrlich gesagt nen Vogel 🙂
Kunde A hat Version 2.3.8.3
Kunde B hat Version 2.3.1.14
Wer ist aktueller? Hat Kunde B schon das Update 2.3.8.3 erhalten? Weil 2.3.1.14 könnte ja später gekommen sein?

Die Supportmitarbeiter werden ein für sowas das ganze Leben lang hassen 😁

Sowas macht man nicht über die Versionsnummer. Schau dir einfach ab, wie MS das macht. Die Versionsnummern unterscheiden sich nur bei Major oder Minor Releases (RTM, SP1, SP2, usw...).

Also wenn ich mir mal mein Outlook 07 ansehe, hat dies eine Major Number, eine Minor Number, und anschließend folgen zwei weitere (vermutlich Patch Level und Buildnumber).

Alles weitere sind Hotfixes, die keine Versionsnummer tragen. Hier müssen nur die Hotfixes wissen, ab welcher Major/Minor Version sie sich installieren dürfen, und ab welcher Major/Minor-Version sie bereits integriert sind. Ebenfalls müssen diese wissen, ob sie in Abhängigkeit zu anderen Hotfixes stehen.

Genau, dies kann aber anhand der Minor Major Number geschehen. Passen die beiden Zahlen zusammen, so kann das Update (Hotfix) installiert werden.