Hallo,

Die Änderungen, oder zumindest einige davon (Bedienelemente, Elemente mit neuen Infos), muss ich ja auch immer in mein (noch unfertiges) Template einpflegen.

Nicht nur Du.

Ich vermute dahinter einen Integerzähler oder hast du an eine klassisch aufgebaute Versionsnummer wie z.B. 2.3.1.96 gedacht?

Einen einfachen int. Zähler, da dieser unabhängig von der Forenversion ist. Die Forenversion kennt also die int. Nummer der Datei, die sie benötigt. Die Datei selbst weiß aber nicht, zu welcher Version sie gehört.

muss ich jeder Datei bei jeder Änderung, die in einen Commit mündet, eine neue Nummer geben.

Jede Datei, die auch tatsächlich geändert wurde, erhält zwischen den Forenversionen eine neue Nummer. Aktuell haben wir die Forenversion 2.4.6. Die contact.inc.php hat bspw. die Version 3. Wenn nun im Zuge der Erneuerungen auf Version 2.4.7 das Kontaktformular geändert wurde, wird die 3 durch eine 4 ersetzt. In der globalen Liste entsprechend:

index.inc.php 12
contact.inc.php 4 // vorher 3 - Einzige Änderung
admin.inc.php 37
....

Die PHP-Dateien könnte man so abfrühstücken. Die bleiben so, wie sie von uns gestellt werden, außer, ja, außer irgendwer baut sich noch eigene Funktionen in die Skripte ein. Dann steht der, auch wenn ich von ihm erwarte, Diffs interpretieren zu können, vor dem gleichen Problem wie einer mit Änderungen am Template. Womit wir wieder beim Auslöser wären.

Ja aber die Wahrscheinlichkeit wäre hier geringer. Es scheint für mich naheliegender, dass einer die Optik ändert als unter Haube zu schrauben. Aber klar, das Problem würde weiterhin besehen aber einen vermutlich deutlich kleineren Kreis an Nutzern treffen.

Demjenigen, der ein eigenes Template benutzt, fehlen im Zweifelsfall nur eine oder ein paar neue Funktionen, wie z.B. bei der 2.4-er Serie die Links, Buttons und die Seite für die Bookmarks. Sie/er macht aber normalerweise nichts kaputt. Um das eigene Template anzupassen, braucht aber auch ein Betreiber mit eigenem Template die Informationen über die konkreten Änderungen um sein Template zu erweitern.

Wenn wir bestimmte Funktionalitäten ändern (PHP), diese dann ins Template (via SMARTY) transportieren, dann ist eben leider jeder betroffen, da u.U. das alte Template gar nicht mehr lauffähig ist. Wenn wir also eine Variable entfernen oder umbenennen, dann trifft das eben alle und es muss dann nachvollziehbar sein, was zu ändern ist im Template/CSS/JavaScript.

- Änderung an der HTML-Struktur. Entfernen, hinzufügen und umbenennen von Elementen, Klassen und IDs. Auch wichtig für eigene JavaScripte, die nach Änderungen im HTML-Quelltext auf nicht mehr existente oder umbenannte Elemente oder Attribute zielen könnten.
- Änderungen in den Sprachdateien. Neue Strings, umbenannte Schlüssel.
- Änderungen im CSS, z.B. auch durch Änderungen im HTML verursachte Umbenennungen von Selektoren (Klassen, IDs).

Die Dokumentation sollte mMn mit Verweis auf die Zeilen/Abschnitte im Quellcode erfolgen und eventuell Codeausschnitte der relevanten Stellen enthalten. Der Aufwand wird bei Major-Releases (2.4, 2.5, etc.) mit neuen Funktionen erheblich. Bei Bugfix-Releases sollte er sich hingegen in Grenzen halten. Wir müssen bloß ein Schema erarbeiten, wie sowas aussehen soll, damit wir das nicht aus Versehen bei jedem Release unterschiedlich gestalten.

Ja, ich denke, dass trifft den Kern. Wie man das dann ausgestaltet, weiß ich im Moment auch noch nicht

Viele Grüße
Micha