Entwicklung des Kerns (Core)

Entscheidungsfindung

CMSimple_XH ist eine von einer freien Community gemeinschaftlich entwickelte Open Source Software, hinter der kein Unternehmen oder Verein steht. Daher gibt es weder einen Chef, noch jemanden, der besondere Befugnis hätte zu entscheiden, in welche Richtung sich die Software entwickelt. Stattdessen haben wir, zumindest für alle kontroversen Änderungen, ein einfaches Abstimmungsverfahren eingeführt, ähnlich wie bei den RFCs von PHP und den PEPs von Python, nur etwas weniger formell. Nach einer Diskussion im Forum oder anderswo steht es jedem frei, ein Issue in unserem Github-Repository einzureichen, um eine Änderung an der Software vorzuschlagen. Nach dem Ermessen des Release-Managers (Versionsverwalter, diese Rolle ist nicht klar definiert und kann wechseln) werden von Zeit zu Zeit durch Hinzufügen eines Voting-Labels diese Vorschläge zur Abstimmung gestellt, was auch im Open Development Forum angekündigt wird. Die Abstimmung ist 18 Tage lang offen. Abgestimmt wird einfach durch das Hinzufügen entsprechender Reaktionen (normalerweise Daumen hoch oder Daumen runter), aber natürlich können auch (vorzugsweise kurze) Kommentare hinzugefügt werden, falls erforderlich. Nach dem Ende der Abstimmung zählt der Release-Manager die Stimmen zusammen (wobei Stimmen von unbekannten Benutzern ignoriert werden können) und entfernt das Abstimmungslabel und ersetzt es durch to be implemented bzw. schließt das Ticket.

Zumindest für weniger kontroverse Änderungen können auch Pull-Requests in unserem Github-Repository eingereicht werden, und wenn niemand etwas dagegen hat, können diese nach einer Weile (mindestens eine Woche) von jedem, der über Commit-Rechte verfügt, zusammengeführt werden. Triviale Fehlerkorrekturen können sofort übernommen werden. In beiden Fällen sollte jedoch auch ein entsprechendes Issue vorhanden sein, damit wir ein umfassendes und aussagekräftiges Changelog haben. Korrekte Refactorings (d.h. solche, die das Verhalten nicht verändern), Tippfehlerkorrekturen usw., können ohne ein entsprechendes Issue committed werden, da diese für die Benutzer normalerweise irrelevant sind.

Veröffentlichungszyklus

Ab CMSimple_XH 1.7.0 folgt das Projekt der semantischen Versionierung. Es gibt keinen fest definierten Zeitplan, aber in der Regel werden mehrmals im Jahr Revisionen veröffentlicht, die nur abwärtskompatible Fehlerkorrekturen bereitstellen. In dringenden Fällen kann eine Revision nur wenige Tage nach der vorherigen Version veröffentlicht werden. Nebenversionen, die möglicherweise neue Funktionen und Verbesserungen einführen und die Abwärtskompatibilität (BC = Backward Compatibility) nicht unterbrechen, werden einige Male im Jahr veröffentlicht, nachdem es mindestens einen Veröffentlichungskandidaten (RC = Release Candidate) gegeben hat. Hauptversionen, die möglicherweise Inkompatibilitäten zu vorherigen Versionen einführen (BC break), erscheinen in größeren Zeitabständen. Hauptversionen haben normalerweise eine umfangreiche Beta- und RC-Phase.

Updates auf neue Revisionen und neue Minor-Releases sollten so einfach gehalten sein wie das Hochladen eines Patches, was normalerweise keine Konfiguration, Sprache oder Stylesheets überschreibt. Major-Versionen hingegen erfordern möglicherweise einen aufwändigeren Update-Prozess, häufig eine Migration.

Die Veröffentlichung einer neuen Hauptversion ist nicht notwendigerweise das Lebensende (EOL = End of life) der vorherigen Hauptversion. Stattdessen kann von Fall zu Fall entschieden werden, wie lange die frühere Hauptversion noch mit Fehler- und insbesondere Sicherheitskorrekturen unterstützt wird.

Git-Zweig-Strategie (branches)

Eng verbunden mit dem Veröffentlichungszyklus ist unsere Git-Verzweigungsstrategie. Alle neuen Entwicklungen (im Gegensatz zu Fehlerkorrekturen) werden im Master-Zweig durchgeführt. Vor der Veröffentlichung einer neuen (Minor- oder Major-) Version wird ein entsprechender Versionszweig vom Release-Manager verzweigt (z.B. 1.8 für CMSimple_XH 1.8.x, oder 2 für CMSimple_XH 2.x.y). Fehlerkorrekturen werden immer auf den niedrigsten noch unterstützten Zweig angewandt und sofort vom Committer nach oben bis zum Master zusammengeführt, auch wenn das zu einem leeren Merge führen würde, weil der Fehler keinen höheren Zweig betreffen würde.