Aus SKM Wiki

[bearbeiten] Release Management

Ausgelieferbare bzw. ausgelieferte Version eines Produktes inkl. Dokumentation.

[bearbeiten] Release Nummerierung

Der Sinn und Zweck einer Release-Nummerierung ist es, Anhand der Nummerierung bestimmte Informationen erkennen zu können. Diese Release-Nummerierung wird aber i.d.R. für den Kunden bzw. die Außenwirkung Angewendet.

Nehmen wir einmal an, dass wir ein Nummerierungschemata der folgenden Art definieren:

Major.Minor.Patch-Build

wobei Major, Minor, Patch und Build jeweils aus einer oder mehreren Ziffern bestehen können.

Beispiele:

• 0.0.12-20
• 0.1.0-1
• 1.0.0-245
• 1.1.0-20

Meistens wird die Nummerierung auch noch durch Zusätze wie z.B. Alpha, Beta, RC oder GA ergänzt.

Es wird bei der Entwicklung meistens festgelegt, dass die Release mit der Nummerierung z.B. 1.1.X zueinander Kompatibel sein muss. Bei der Verwendung einer Server- und einer Client-Kompoenten, dass hier die Server-Komponente ausgetauscht werden kann aber weiterhin mit einer Client-Komponente mit entsprechnder Nummerierung zusammenarbeiten sollte. Die Unterschiedlichen Bereiche der Nummerierung (Major, Minor, Patch) bezeichnen hierbei unterschiedliche Implementierungsergänzungen und/oder Veränderungen. Wenn von einer Patch-Release gesprochen wird, dann ist gemeint (1.0.0, 1.0.1, 1.0.2 etc.), dass meist einige Fehler behoben wurden. Es gibt auch manchmal die Notwendigkeit, dass bei jeder Änderung bzw. Behebung eines Fehler die Nummerierung diese Tatsache wiederspiegeln muss, dann besteht eine Nummerierung meist aus einer weiteren Nummer.

Major.Minor.Patch.BugFix

Hierbei wird die BugFix Nummer bei jeder Behebung eines Fehler entsprechend erhöht. Die Patch-Nummer dient dann meist dazu, die Behebung eines Reihe von Bug-Fixes zu Bündeln.

Ist eine Änderung der Minor Nummer angesagt, ist meistens gemeint, dass Feature hinzugefügt wurden (1.2.X, 1.3.X etc.). Wenn sogar die Major Nummerierung geändert wird, geht damit meist auch die Kompatibilität zu den 1.X Releases verloren und ein ganzer Katalog von neuen Funktionen wird hinzugefügt oder gar eine neue Implementierung wurde durchgeführt, weil z.B. Festgestellt wurde, dass mit dem bisherigen Design bestimmte Funktionalitäten nicht Implementiert werden können.

Der letzte Teil der Nummerierung, die sog. Build-Nummer wird manchmal einfach nur angehängt, um den Build zu kennzeichnen aus dem die öffentliche Release resultierte.

[bearbeiten] Entwicklungsstadien

Die Entwicklungsstadien, die eine Software durchläuft:

• Alpha
  • Bezeichnet meist eine erste lauffähige Version einer Software. Es sind meist einige Grundlegende Eigenschaften (Features) enthalten, es fehlen aber auch noch einige Bestandteile. Meist wird eine Software in diesem Entwicklungsstadium Alpha-Release oder Alpha-Version gennant. Es ist klar, dass eine solche Release definitiv nicht für den produktiven Einsatz geeignet ist. Die Kennzeichnung einer Alpha-Release ist oft an der Nummer 0 in der Major und Minor Nummer zu erkennen.
• Beta
  • Ein Beta Version wird meist Erstellt, um z.B. Kunden einen Ersten Eindruck der Software zu bieten. Dabei sind meistens alle Features implementiert, aber nicht vollständig getestet. Je nach Definition eine Beta-Release wird auch manchmal der Beginn der Beta-Phase mit dem sog. Feature-Freeze gleich gesetzt. Das bedeutet, dass keine weiteren Features mehr hinzugefügt werden. Es müssen aber noch z.B. der Abnahme- und/oder Integrationstest durchgeführt werden.Die Kennzeichnung einer Beta-Release ist oft an der Nummer 0 in der Major Nummer zu erkennen.
• Release Candidates (RC):
  • Der Release Candidate oder Freigabekandidat bezeichnet den Stand der Softwareentwicklung, in der alle Funktionen enthalten sind. In diesem Stadium wird nur noch getestet und bei Auftreten eines oder mehrere Fehler werden diese Behoben und danach wird ein neuer RC erstellt. Um die unterschiedlichen Release-Candidates zu Unterscheider wird hier einfach noch eine Nummerierung angehängt (RC1, RC2, ...). Wenn nun alle Tests abgeschlossen sind, dann wird der letzte RC als die endgültige Release bezeichnet.
• Final oder Global Availability (GA)
  • Endgültige Release einer Software. Dabei wurden alle Tests durchgeführt. Eventuelle Fehler/Unverträglichkeiten etc. die ekannt sind werden in einer Known-Bugs/Known-Problems Liste aufgeführt
• Fehler nach der Veröffentlichung
  • Wenn nun seitens der Kunden Fehler in einer Veröffentlichen Release gefunden werden, werden seitens des Herstellers sog. Hotfixes, Patches etc. zur Verfügung gestellt.