Hallo,

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 …

Gut.

… 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.

Also eine neue Zählernummer nur bei Release einer neuen Version, nicht bei jedem Commit, von dem die Datei betroffen ist. Das verringert den Aufwand erheblich.

Die PHP-Dateien … bleiben so, wie sie von uns gestellt werden, … 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.

… das Problem würde weiterhin bestehen aber einen vermutlich deutlich kleineren Kreis an Nutzern treffen.

Das ist klar.

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.

Korrekt.

- Ä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

Ich stöbere gerade in den Hilfedokumenten von Github, um herauszubekommen, welche Automatismen existieren, um mit Markdown ein navigierbare Hilfe mit anspringbaren Zwischenüberschriften zu erstellen. Sieht gut aus.

Tschö, Auge

PS: Ich mache daraus mal einen eigenen Thread.