Dieser Beitrag wurde zuletzt am 2021-06-28T04:00:00Z aktualisiert, um die aktuellen Prozesse zu beschreiben.
Hallo zusammen! Hier gibt es mehrere Themen zu behandeln. Mal sehen, ob ich sie alle abdecken kann.
Dies war eine bewusste Entscheidung unsererseits. Wir haben kein formales Releasesystem für unsere Beta-Releases. Wir veröffentlichen ein neues Release, wenn es für uns sinnvoll ist. Daher gibt es in der Regel wenig Vorwarnung vor einem Release und somit wenig Zeit, Release-Notizen zu verfassen. @codinghorror entschied, dass es keinen Sinn ergab, ein Release hinauszuzögern, nur um auf die Notizen zu warten.
Beta-Releases werden nun zwischen dem Engineering-Team und dem Community-Team koordiniert. Release-Notizen sollten zur gleichen Zeit wie Beta-Releases veröffentlicht werden, wenn nicht sogar kurz davor.
Sie werden keine Release-Notizen für beta1 sehen. Um Verwirrung zu vermeiden, werden Release-Notizen für alle Beta-Releases verfasst. Auch stabile Releases erhalten Notizen. Beachten Sie jedoch, dass beta1 (jeder Version) praktisch identisch mit dem letzten Beta der vorherigen Version ist.
Um zu verstehen, warum dies so ist, muss ich etwas darüber erklären, wie unsere Branches konfiguriert sind.
Für unsere Zwecke hier müssen wir vier Branches von Discourse kennen: main, tests-passed, beta und stable.
Main:
Wenn ein neuer Commit zu Discourse hinzugefügt wird, befindet er sich im Main-Branch. Main ist der absolut neueste (aktuellste) Branch von Discourse, und wir empfehlen niemandem, seine Seite mit dem Tracking des Main-Branches zu betreiben.
Tests-passed:
Wenn ein neuer Commit in den Main-Branch gepusht wird, führt unser Build-Server automatisch alle unsere Tests gegen den neuesten Code aus. Sobald alle bestanden sind, wird der Commit unserem tests-passed-Branch hinzugefügt. Dies ist der Branch, auf dem alle Discourse-Sites standardmäßig laufen.
Beta:
Alle paar Wochen pushten wir die aktuellen Commits von tests-passed nach beta. Wir nutzen Beta als „Meilenstein“, um eine Sammlung von Commits zu veröffentlichen, die mehr Sites ausführen und testen sollen. Wir veröffentlichen auch ein Beta, wenn wir eine wichtige Sicherheitskorrektur haben, die Sites erhalten sollen. Wenn ein Beta gepusht wird, erhalten alle Sites, die auf tests-passed oder beta laufen, die E-Mail „neues Update verfügbar“. Sites, die tests-passed ausführen, werden auf die aktuellen tests-passed-Commits aktualisiert (einschließlich aller neuen Commits, die nach dem Beta gepusht wurden), während solche auf beta dies nicht tun.
Stable:
Alle 4–6 Monate veröffentlichen wir ein neues stable-Build. Etwa 2 Wochen vor dem Pushen von Stable veröffentlichen wir unser letztes Beta. Anschließend beobachten wir unsere Logs genau, um etwaige verbleibende Fehler zu erkennen und neue Features/riskante Änderungen zu vermeiden. Sobald wir mit dem Zustand des aktuellen Betas zufrieden sind, pushten wir nach Stable.
Unter Berücksichtigung des Obigen, nehmen wir 2.0.0 als Beispiel. Wir haben am 16. Mai 2.0.0.beta10 gepusht. Alle Benutzer, die tests-passed oder beta ausführen, erhielten eine E-Mail (und wir gehen davon aus, dass sie aktualisiert haben). Ich habe Release-Notizen für dieses Beta verfasst. Etwa 2 Wochen später, am 31. Mai, haben wir dieses Build als 2.1.0 nach Stable gepusht. Um sicherzustellen, dass Benutzer, die auf tests-passed oder beta laufen, ebenfalls das Update erhalten, haben wir dasselbe Build als 2.1.0.beta1 veröffentlicht.
Macht das alles Sinn? Gibt es etwas, das ich mit den release-notes in #feature:announcements anders machen könnte, um dies klarer zu machen?