Release cycle de DE

Veröffentlichungszyklus

ASF verwendet die gängige C# Versionierung mit 4 Zahlen, geschrieben als A.B.C.D. Jede veröffentlichte Version ist zeitlich fixiert und zeigt auf die Version des Quellcodes, aus dem sie gebaut wurde (zusammen mit dem Release). Wir haben nicht die Absicht eine bisher veröffentlichte Version zu löschen, solange unser Hosting-Provider (GitHub) kein Problem damit hat sie für die Zukunft zu erhalten. Aus diesem Grund können Sie jederzeit zu einer vorherigen Version zurückgehen ohne manuell Kopien anfertigen zu müssen.

Generell versuchen wir bei der Versionierung von ASF unser Bestes, um der semver-Spezifikation nach dem muster MAJOR.MINOR.PATCH auf den letzten 3 Nummern (B.C.D) zu folgen. Diese drei Nummern befinden sich in direktem Zusammenhang mit dem Quellcode von ASF. Die signifikanteste Nummer A ist ein Indiz für Änderungen, die über den Quellcode von ASF hinausgehen und üblicherweise direkt das Fundament des Programms beeinflussen.

ASF als Projekt versucht mehr oder weniger eine veröffentlichte Version pro Monat zu haben, die durch eine Erhöhung der C-Nummer indiziert wird. Um eine solche Versionsveröffentlichung möglich zu machen, haben wir kleinere pre-releases, die an erfahrene Benutzer gerichtet sind, und die als kleine Meilensteine von Änderungen dienen. Diese werden veröffentlicht sobald genügend Änderungen im Vergleich zum vorherigen pre-release vorhanden sind um sich auf diese fokussieren zu können. Wenn ein pre-release als stabil und genug gereift und ohne kritische Änderungen, die im Vergleich zur letzten stabilen Version korrigiert werden sollten, angesehen wird, wird dieser als die neue stabile Version veröffentlicht; was einen neuen monatlichen Zyklus für den nächsten startet.

Während wir unser Bestes geben, um sicherzustellen, dass auch unsere Pre-Releases relativ stabil sind, sollte beachtet werden, dass Vorabveröffentlichungen sorgfältig für die Ausführung in Produktionsumgebungen evaluiert werden sollten. Vorabversionen können kritische Fehler und andere defekte Funktionalitäten enthalten. Aus genau diesem Grund geben wir sie überhaupt erst frei – so können wir dieses Chaos in unseren stabilen Builds vermeiden und zuverlässige Software anbieten. Falls Sie nicht bereit sind, ein höheres Risiko zu akzeptieren, das sich aus der Verwendung potenziell instabiler Software ergibt, dann vermeiden Sie bitte die Verwendung unserer Vorabversionen, und halten Sie sich stattdessen an unseren neueste stabile Version, die für die Mehrzahl der Benutzer besser geeignet ist.

Abhängig von der Menge an Änderungen im Zyklus, wird es in der Regel einen einzigen C Versionssprung (von vorherigen stabil), und D Sprung für jede Vorabversion auf erforderlicher Basis. Allerdings kann der Zyklus mittendrin beginnen (oder wechseln) nach B, oder sogar zu A springen, sofern Änderungen größeren Ausmaßes eingeführt werden. Solche Wechsel deutet darauf hin, dass der aktuelle Veröffentlichungszyklus potenziell länger als gewöhnlich bis zur stabilen Phase benötigt, und bis dahin sorgfältig getestet werden sollte. Beachten Sie, dass sich die von uns vorgenommenen Semver-Änderungen nur auf die zuvor veröffentlichte stabile Version beziehen. Wir verfolgen nicht die Versionierung über Vorabveröffentlichungen in einem Zyklus selbst – das heißt Version 1.0.1.2 könnte eine neue Funktion haben, die es in 1.0.1. nicht gab, solange die zuvor markierte stabile Version aus der 1.0.0.X Familie stammt. Gleichermaßen könnte es auch über zwei Veröffentlichungen des gleichen Zyklus hinweg zu erheblichen Veränderungen kommen. Das gilt besonders, wenn wir noch über die endgültige Form der neu eingeführten Funktionalität oder Ähnliches entscheiden.

Versionssprung	Semver	Beispiel der Änderungen
A		Wichtige .NET Laufzeitänderungen, Kernänderungen, erhebliche Änderungen, die über ASF Codebase hinausgehen, Dinge, die Ihre Katze essen könnten
B	Major	Geringe .NET Laufzeitänderungen, Änderungen im ASF-Quellcode, große Code-Änderungen, die über eine geringfügige Klassifizierung hinausgehen
C	Minor	Neue monatliche Zyklen, in der Regel neue Funktionalitäten, Befehle, Konfigurationseigenschaften oder andere Änderungen, die die bestehende Installation nicht stören
D	Patch	Neue Vorabveröffentlichung, welche Teil eines bestehenden Zyklus ist (angezeigt durch eine aufsteigende Nummer), kritische Fehlerkorrekturen an existierenden stabilen Releases, die keine Code-Änderungen über die notwendige hinaus einführen

Bitte bedenke, dass neu eingeführte Features und Änderungen bis zu einem späteren Zeitpunkt undokumentiert sein können (z. B. im Wiki), da die Dokumentation in der Regel geschrieben wird, sobald der endgültige Quellcode des jeweiligen Features fertig ist (um uns Zeit zu sparen und die Dokumentation nicht jedes Mal neu zu schreiben, wenn wir uns dazu entscheiden die Funktion an der wir gerade arbeiten zu ändern). Da die Vorabveröffentlichung möglicherweise „ Work-in-Progress“-Quellcode enthält, der noch keine endgültige Form hat, wird die Dokumentation in einem späteren Stadium der Entwicklung erscheinen. Dasselbe gilt für das allgemeine Änderungsprotokoll, das für eine bestimmte Vorabveröffentlichung erst einige Zeit später verfügbar sein könnte. Wenn Sie sich also entscheiden, eine Vorabveröffentlichung zu verwenden, dann seien Sie darauf vorbereitet von Zeit zu Zeit einen Blick in die ASF Commits zu werfen. Natürlich gilt der Mangel an Dokumentation nur für Vorabveröffentlichungen – jede stabile Version muss immer ein vollständiges Änderungsprotokoll und eine Dokumentation im Wiki haben, sobald es veröffentlicht wird.

Das genaue Änderungsprotokoll, welches eine Version mit einer anderen vergleicht, ist auf GitHub immer verfügbar – durch Commits und Programmänderungen. Im Veröffentlichungsprozess neigen wir dazu, nur Änderungen zu dokumentieren, die wir für wichtig halten, zwischen der letzten stabilen und aktuellen Version. Solch ein kurzes Änderungsprotokoll ist nie vollständig. Wenn Sie also jede Änderung sehen möchten, die zwischen den Versionen passiert ist (etwa unsere Abhängigkeits-Upgrades) – benutzen Sie bitte GitHub dafür.

ASF Projekt wird durch unseren kontinuierlichen Integrationsprozess betrieben. Jede Version soll reproduzierbar sein; daher sollte es kein Problem sein, Quellcode (enthalten in der Veröffentlichung) der gegebenen Version zu nehmen und selbst zu kompilieren und das gleiche Ergebnis zu erhalten, das über unsere vorkompilierten Binärdateien verfügbar ist. Wir vermeiden typischerweise selbst das Kompilieren von Veröffentlichungen; solange die Systeme operativ sind, stammen die veröffentlichten Binärdateien direkt aus unserem CI-Prozess.