Release cycle de DE

Veröffentlichungszyklus

ASF verwendet die gängige C#-Versionierung, nämlich A.B.C.D. Die Version wird nach der Veröffentlichung der aktuellen Version auf GitHub erhöht. Jede einzelne Version, die bisher veröffentlicht wurde, ist auf GitHub verfügbar (im eingefrorenen Zustand) und wird nicht mit der Zeit verschwinden, daher ist es immer möglich, auf alle Versionen zurückzugreifen, ohne dass man selbst Kopien machen muss.

Im Allgemeinen ist die ASF-Versionierung sehr einfach - wir verwenden Zahlen von 0 bis 9 anstelle von A, B, C und D. Ein Versions-Bump erhöht D, wenn neues D zu Zahl 10 führen würde, erhöhen wir stattdessen C und setzen D wieder auf 0, und so weiter. Die Veröffentlichung einer neuen Version soll als ASF-Meilenstein behandelt werden, eine Version mit vorgegebenem Funktionsumfang, die implementiert und einsatzbereit ist, ohne Regressionen gegenüber der vorherigen zu verursachen. Manchmal entscheiden wir uns vielleicht dazu, dass eingeführte Änderungen sehr wichtig sind und stoßen stattdessen auf C, B oder sogar A, obwohl das ziemlich selten ist (und normalerweise auf einige brechende Änderungen hinweist).

ASF-Veröffentlichungen werden in zwei Kategorien unterteilt - stabile Versionen und Vorabveröffentlichungen.

Stabile Veröffentlichungen sollen ordnungsgemäß und ohne bekannte Regressionen (zum Zeitpunkt der Veröffentlichung) im Vergleich zu früheren Veröffentlichungen funktionieren. Wir neigen dazu, die stabile Version entweder nach einer längeren Zeit des Testens der Vorabversion oder als Version zu veröffentlichen, die Fehler der vorherigen stabilen Version behebt ohne neue einzuführen. In sehr seltenen Szenarien (z.B. brechende Änderungen von Steam) können wir uns auch dazu entscheiden so schnell wie möglich eine neue stabile Version zu veröffentlichen. Im Allgemeinen sollten diese Versionen jedoch normalerweise sehr gut funktionieren, da wir eine Version nicht als stabil markieren, wenn sie zu einem schlechteren allgemeinen Zustand im Vergleich zu früheren stabilen Versionen führt. Natürlich basiert ein solcher "Gesamtzustand" auf Berichten und Rückmeldungen, die wir während der Entwicklung der Vorabversion erhalten, so dass es leider immer noch möglich ist, dass einige Fehler durchschlüpfen und nach einer stabilen Version entdeckt werden, einfach weil niemand von uns während der Entwicklungsphase darauf gestoßen ist. Glücklicherweise ist es für uns ziemlich selten, dass so etwas passiert und wir neigen dazu es so schnell wie möglich in einer anderen nachfolgenden stabilen Version zu beheben.

Vorabveröffentlichungen sind häufiger und führen in der Regel zu Änderungen im laufenden Betrieb, Vorschlägen oder neuen Implementierungen. Die Vorveröffentlichung ist nicht garantiert stabil, obwohl wir immer versuchen, einige einfache Tests durchzuführen, bevor wir sie auf GitHub übertragen, so dass es sich niemals um eine Version handeln sollte die in Bezug auf den praktischen Gebrauch völlig fehlerhaft ist. Der Hauptpunkt von Vorabveröffentlichungen ist es, Rückmeldungen von fortgeschritteneren Benutzern zu erhalten und neu eingeführte Fehler (falls vorhanden) zu erkennen, bevor sie in die stabile Version kommen. Die Qualität dieser Arbeit hängt stark von der Anzahl der Tester, den Fehlern die auf GitHub gemeldet werden und der allgemeinen Rückmeldung ab.

Vorabveröffentlichungen sollten üblicherweise so gut funktionieren wie stabile Versionen und der einzige Unterschied zwischen diesen beiden ist einfach die Tatsache, dass sie von mehr Benutzern getestet werden. Dies liegt daran, dass ASF ein fortlaufendes Projekt ist, was bedeutet, dass es möglich sein sollte, dieses zu jedem beliebigen Zeitpunkt zu erstellen und zu verwenden und dass die Versionierung zu deiner Bequemlichkeit vorgenommen wird - als Meilenstein des Wechsels zwischen einer Version und einer anderen. Dennoch, wenn du dich dazu entscheidest Vorabveröffentlichungen zu verwenden, solltest du normalerweise ein etwas fortgeschrittenerer Benutzer sein, da Vorabveröffentlichungen normalerweise kleinere ASF-Meilensteine sind, und es ist durchaus möglich, dass selbst wenn etwas anständig zu funktionieren scheint, es Dinge gibt, die noch nicht unbedingt funktionieren oder getestet wurden - die ASF-Entwicklung auf GitHub zu verfolgen und die Änderungsprotokolle sorgfältig zu lesen ist das Minimum, das du tun musst, wenn du Vorabveröffentlichungen verwenden willst (zu deinem eigenen Nutzen). Darüber hinaus gibt es Momente, in denen wir aktiv etwas Bestimmtes testen, wie z.B. Konfigurationsänderungen, neu geschriebener Quellcode für eine bestimmte Sache oder Kernänderungen. Lies in diesem Fall immer das Änderungsprotokoll, da eine solche Vorabveröffentlichung instabiler sein könnte als andere.

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, kann die Dokumentation in einem späteren Stadium der Entwicklung eintreffen. 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 du dich also entscheidest, eine Vorabveröffentlichung zu verwenden, dann sei 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.

Eine Vorabveröffentlichung kann nach einiger Zeit als stabil angesehen werden. Dies gilt insbesondere dann, wenn in der Zwischenzeit keine Änderungen vorgenommen wurden und es keinen Sinn macht, den Versionswechsel nur um der stabilen Veröffentlichung willen durchzuführen. Es wird auch sehr oft gemacht, wenn die Vorabversion als "stabiler Veröffentlichungskandidat" angesehen wird, da es fortgeschrittenen Benutzern erlaubt, sie zu testen, bevor sie als stabil markiert wird, so dass das Risiko der Einführung von Fehlern viel geringer ist, weshalb dies das häufigste Muster ist, wenn es sich um ASF-Veröffentlichungen handelt:

Stable 1.0 -> Pre 1.1 -> Pre 1.2 -> ... -> Pre 1.7 (RC) -> Stable 1.7 (gleich wie Pre 1.7)

Im Allgemeinen werden ASF-Veröffentlichungen jedoch freigegeben, wenn sie fertig sind, was zu einem nicht vorhersehbaren Veröffentlichungsplan führt. Normalerweise gibt es am Ende eines jeden wichtigen Features oder einer Änderung eine Vorabversion und eine stabile Version, wenn nach einiger Zeit (ein paar Tage) seit der Verfügbarkeit der Vorabversion keine Fehler mehr gefunden werden. Wir streben mehr oder weniger eine stabile Veröffentlichung pro Monat an, es sei denn, es gibt einige kritische Probleme zu lösen oder ähnliches. Vorabveröffentlichungen finden nach Bedarf statt, wenn wir das Gefühl haben, dass es genug Dinge gibt, die seit der Veröffentlichung der letzten Version getestet werden müssen. Je nachdem, wie beschäftigt die ASF-Entwicklung im gegebenen Moment ist, kann dies von einigen wenigen bis zu einem Dutzend Vorabversionen zwischen den einzelnen stabilen Versionen sein.

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, also wenn du jede Änderung sehen möchtest, die zwischen einer Version und einer anderen passiert ist - benutze bitte GitHub dafür.

Das ASF-Projekt basiert auf einem kontinuierlichen Integrationsprozess und wird von zwei unabhängigen Diensten getestet - AppVeyor, die ASF unter Windows testen, und Travis, die ASF unter Linux und OS X testen. Jeder Build soll reproduzierbar sein, deshalb sollte es kein Problem sein, sich die Quelle (die im Release enthalten ist) der gegebenen Version zu schnappen und selbst zu kompilieren, indem man das gleiche Ergebnis erhält wie das, das über eine Binärdatei verfügbar ist.

Als Extra, zusätzlich zu den ASF stabilen Versionen und Vorabveröffentlichungen, kannst du auch den neuesten automatisierten AppVeyor Build hier finden, der typischerweise aus dem neuesten, noch nicht enthaltenen Commit besteht. Aufgrund der Automatisierung und des Fehlens von Tests werden diese Builds in keiner Weise unterstützt und sind typischerweise nur für Entwickler verfügbar, die den neuesten ASF GitHub Snapshot in Objektform erstellen müssen, so dass sie sich nicht selbst kompilieren müssen. Nichts garantiert, dass ASF im Zustand master ordnungsgemäß funktioniert. In seltenen Fällen können diese Builds auch verwendet werden, um zu überprüfen, ob ein noch nicht freigegebenes Commit tatsächlich ein bestimmtes Problem oder einen Fehler behoben hat, ohne auf die Änderung zu warten, die in der Vorveröffentlichung landet. Wenn du dich entscheidest, diese automatisierten Builds zu verwenden, stelle bitte sicher, dass du über fundiertes Wissen in Bezug auf ASF verfügst, da es die höchste "Stufe" der fehlerhaften Software ist. Wenn du keinen triftigen Grund hast, bist du normalerweise schon am Rande der Entwicklung, indem du die Vorabversionen verfolgst - AppVeyor-Builds werden als Zusatz zu Vorabversionen angeboten, hauptsächlich um zu überprüfen, ob ein bestimmtes Problem, an dem wir gerade arbeiten, behoben wurde. Diese Builds sollten nicht in einer Produktionsumgebung verwendet werden.