Ich verfolge häufig, was bei der Entwicklung von Discourse passiert. Gibt es ein laufendes Änderungsprotokoll, das aktuelle Implementierungen zeigt, oder eine Roadmap?
Haben Beta-Snapshots ein Änderungsprotokoll, das ich übersehen habe?
Zum Beispiel sehe ich bei der aktuellen Beta-Version weder auf der Release-Seite noch im Source-Repo-Branch irgendeine Art von Änderungsprotokoll…
Wir halten alles hier auf Meta, nicht auf GitHub.
Eine Übersicht aller unserer wichtigsten Releases sowie der aktuellen Planungen für zukünftige Releases findest du hier: https://meta.discourse.org/c/releases
Release-Hinweise veröffentlichen wir hier: Topics tagged release-notes
Vielen Dank für die Klärung. Es könnte hilfreich sein, dies auch auf GitHub zu verlinken, damit die Leute es leicht über einen „Changelog“-Link ganz oben finden können, wie ich es bei anderen Projekten gesehen habe.
Warum gibt es keine Beiträge für kleinere Änderungen? Zum Beispiel enthielten die Release Notes für Version 2.6.7 eine Sicherheitskorrektur.
Ich muss Tags vergleichen, um die Commits zu prüfen und zu bestätigen, dass es Sicherheitskorrekturen gab.
Entschuldigung, ich bin mir nicht sicher, ob ich dem folgen kann… Wenn in den Release Notes von einer Sicherheitskorrektur die Rede war, warum musstest du dann Tags vergleichen?
Wir veröffentlichen keine Versionshinweise für den stable-Branch, portieren aber auch nur größere Fehlerkorrekturen oder Sicherheitsprobleme zurück. Daher lautet die Antwort auf die Frage „Sollte ich während der Nutzung des ‚stable’-Branches auf eine neuere Punktversion aktualisieren?
Also, wie unterscheiden sich Minor- und Tiny-Releases?
Beispiel: Sind Tiny-Releases ausschließlich Bugfixes und Sicherheitsupdates?
Sind Minor-Releases neue Funktionen oder etwas anderes?
Laut @Falcos Beitrag sollten wir unabhängig vom Release-Typ immer ein Upgrade durchführen.
Kleinere und winzige Releases definieren – wir sind uns nicht sicher, ob wir diese Begriffe verwenden.
Ich wollte mal fragen, ob ihr eine ähnliche semantische Versionierung wie unter https://semver.org/ verfolgt.
Beispiel: 2.6.7 entspricht Major.Minor.(Tiny oder Patch)
Wir folgen nicht strikt dem Semantic Versioning, nein. Wir praktizieren eine kontinuierliche Entwicklung. Versionsnummern dienen eher als Meilensteine denn als strikte Semantic Versioning. Standardmäßig können Websites jederzeit auf den neuesten Code aktualisieren; sie sind nicht auf eine bestimmte „Release