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 kannst Du 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.

While we're doing our best to ensure that even our pre-releases are relatively stable, it should be noted that pre-releases should be carefully evaluated when running in any production environment. Pre-releases might have critical bugs and otherwise broken functionality, which is exactly why we're releasing them to begin with - so we can avoid all of that mess in our stable builds and offer reliable software. If you're unwilling to accept higher risk that comes from using potentially unstable software, please avoid using our pre-release builds and stick with our latest stable build instead, which is more appropriate for majority of users.

Depending on amount of changes in the cycle, usually there will be a single C version bump (from previous stable), and D bumps for every pre-release on as-needed basis. However, when introducing changes with far bigger scope, especially breaking changes, the cycle might start from (or switch in the middle) to B or even A bump - such switch indicates that current release cycle has a potential to be more unstable than usual, and should be tested carefully. Keep in mind that semver changes we're making relate only to previously released stable version, we do not track versioning across pre-releases in a cycle themselves, which means that version 1.0.1.2 might have a new feature that 1.0.1.1 didn't have, as long as the previously marked stable release is from 1.0.0.X family. Likewise, there could be major breaking changes even across two pre-releases from the same cycle, which is especially true when we're still deciding about the final shape of newly-introduced functionality or similar.

Version bump	Semver	Beispiel der Änderungen
A		Major .NET runtime changes, foundation changes, breaking changes that are beyond ASF's codebase, stuff that might eat your cat
B	Major	Minor .NET runtime changes, breaking changes in ASF codebase, major code edits that go beyond minor classification
C	Minor	New monthly cycles, usually introducing new functionalities, commands, configuration properties or other changes that do not break the existing setups
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. Every build is supposed to be reproducible, therefore it should not be a problem to grab source (included in the release) of given version and compile yourself receiving the same result as the one available through our precompiled binaries. 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.