Neue Programmversionierung

Unser neues Nummernschema für Software-Versionen folgt einer klar definierten Struktur, die sowohl semantische Versionierung als auch branchspezifische Informationen umfasst. Hier erklären wir die Details dieser Struktur und wie Sie die Versionsnummern interpretieren können.

Allgemeiner Aufbau der Versionsnummer

Eine typische Versionsnummer sieht wie folgt aus:

v0.1.2-dev-87f8955

Bestandteile

Semantische Versionierung (v0.1.2)

• MAJOR: Erhöht sich bei inkompatiblen Änderungen.
• MINOR: Erhöht sich bei neuen Funktionen, die kompatibel bleiben.
• PATCH: Erhöht sich bei Fehlerbehebungen und kleinen Anpassungen. Bei einem offiziellen Release ist nur diese Nummer vorhanden (z. B. v1.0.0).

Branchname (dev)

• dev: Hauptentwicklungszweig.
• feature.: Feature-Entwicklungszweige für neue Funktionen.
• bug.: Fehlerbehebungszweige.
• custom.: Individuelle Anpassungen, z. B. Filtertechniken von Nutzern.

Commit-Hash (87f8955)

• Ein eindeutiger Identifier des Commits, der diese Version beschreibt. Dies ist nützlich, um genau nachzuverfolgen, welche Änderungen in der Version enthalten sind.

Branches und ihre Bedeutung

Hauptentwicklungsbranch (dev)

• Beinhaltet den aktuellsten Stand der Weiterentwicklung.
• Wird für neue Features, Verbesserungen und Tests genutzt.

Feature-Branches (feature.)

• Entsprechen spezifischen neuen Funktionen.
• Beispiele: feature.filter-optimization, feature.ui-redesign.

Bugfix-Branches (bug.)

• Dienen der Behebung von Fehlern in der Software.
• Beispiele: bug.login-issue, bug.data-corruption.

Custom-Branches (custom.)

• Ermöglichen nutzerspezifische Anpassungen, insbesondere bei Filtertechniken.
• Beispiele: custom.special-filter, custom.client-specific.
• Filter sind ein zentrales Feature der Software und können individuell hinzugefügt werden.

Beispielinterpretation

v0.1.2-dev-87f8955

• v0.1.2:
  – Major-Version 0: Noch in der frühen Entwicklungsphase.
  – Minor-Version 1: Neue Funktionalitäten seit der letzten Minor-Version.
  – Patch-Version 2: Kleinere Fehlerbehebungen oder Optimierungen.
• dev:
  – Entwicklungszweig ist der Hauptentwicklungsbranch.
• 87f8955:
  – Eindeutige Commit-ID zur Nachverfolgung.

v1.3.0-feature.filter-improvements-4ac12d8

• v1.3.0:
  – Major-Version 1: Stabile Hauptversion.
  – Minor-Version 3: Neue Funktionen seit der letzten stabilen Version.
  – Patch-Version 0: Keine Fehlerbehebungen seit dem letzten Minor-Release.
• feature.filter-improvements:
  – Branch für die Verbesserung von Filtertechniken.
• 4ac12d8:
  – Commit-ID der spezifischen Änderung.

v1.3.0-feature.filter-improvements-4ac12d8

• v1.3.0:
  – Major-Version 1: Stabile Hauptversion.
  – Minor-Version 3: Neue Funktionen seit der letzten stabilen Version.
  – Patch-Version 0: Keine Fehlerbehebungen seit dem letzten Minor-Release.
• feature.filter-improvements:
  – Branch für die Verbesserung von Filtertechniken.
• 4ac12d8:
  – Commit-ID der spezifischen Änderung.

v2.0.1-custom.client-request-bcdef12

• v2.0.1:
  – Major-Version 2: Größere, nicht abwärtskompatible Änderungen.
  – Minor-Version 0: Erste Version dieses Releases.
  – Patch-Version 1: Fehlerbehebung.
• custom.client-request:
  – Nutzerdefinierter Branch mit spezifischen Anpassungen.
• bcdef12:
  – Commit-ID der Änderung.

Fazit

Die Versionssemantik der Software bietet Ihnen eine transparente und strukturierte Möglichkeit, den Entwicklungsstand und die Branch-Herkunft einer Version nachzuvollziehen. Dank dieser Systematik können Sie als Nutzer ebenso wie alle Entwickler effizient auf spezifische Versionen und Anpassungen zugreifen.