Solange man das noch klären kann, ist alles gut.
Der Hintergrund ist, wenn wir jetzt beide daran arbeiten, ist es sehr wichtig das wir auch beide die gleiche Codebase nutzen. Es würde unnötig umständlich werden, wenn du mit Version b) und ich mit Version a) arbeiten würden. Denn in dem Fall hätte ich jetzt quasi mit deinem LB Mirror gearbeitet. ^^
Jut, dann lösche ich das bei mir im TB nochmal komplett und fange frisch mit dem aktuellen Repo Stand an.
Okay, ich würde vorschlagen die bisherigen Releases und Tags erstmal alle zu löschen und keine weiteren Releases zu erstellen, bis wir beide unsere jeweiligen Änderungen drin haben und eine testfähige und vor allem gemeinsame Basis haben. Bei jeder Änderung ein neues Release zu machen ist zum einen unnötiger Aufwand und zum anderen wenig sinnvoll, solange wir mitten im bauen sind. Ein Release kann ausserdem dazu verleiten, das als Release fürs LB zu betrachten. Nicht jeder der über den Fork stolpert liest dieses Thema hier.
Was meinst?
Vorab-Releases können übrigens auch explizit als "Pre-release" gekennzeichnet werden, siehe LFWWH bei den Versionen <2.0.0:
https://github.com/LukeWCS/lf-who-was-here-2/releases
Hier die Details die ich nicht mehr im anderen Thema schreiben wollte.
Wegen Versionsprüfung. Diese ist ist in mehrfacher Hinsicht seltsam. Dazu wird ausgerechnet Curl implementiert samt Mozilla SSL Zertifikatspaket. Ich kann nicht nachvollziehen, warum man das so umständlich machen muss/will. Wenn man wirklich eine eigene Versionsprüfung im ACP Modul realisieren wollte, kann man das ganz simpel mit fertigen PHP Funktionen realisieren. Und nicht mal das muss man, weil phpBB ja schon eine Funktion für Versionsprüfung bietet, nämlich genau die, die der ExtMgr auch nutzt. Dazu kommt, dass Recent Topics keine Ext ist, bei der man regelmässig ins ACP Modul gehen würde. Die wird normal einmal eingestellt und gut ist. Schon alleine deswegen ist eine extra Versionsprüfung im ACP Modul wenig sinnvoll. Die Benutzer sind es eh gewöhnt, dass man Ext Versionen simpel alle auf einmal im ExtMgr prüfen kann.
Etwas wegen Versionnummer, ich weiss nicht, ob du das "Thanks For Posts" Fiasko mitbekommen hast. Da gabs (und gibt es immer noch) ein prima Chaos, weil viele Benutzer nie wirklich mitbekommen haben, dass davon zwei völlig unabhängige Entwicklungen existieren. Ich bin einer von denen:
viewtopic.php?p=1385730#p1385730 . Hat mich allerdings nicht direkt betroffen, weil ich das nur im TB hatte.
Darum:
1. Um auf der sicheren Seite zu bleiben, würde ich vorschlagen, das wir nur solche Änderungen vornehmen, bei denen keine neuen Migrationen nötig sind.
2. Was hältst du davon, wenn wir unsere Sub-Versionen entsprechend in die Versionsnummer einbetten? Bei phpBB und CDB gelten 3 Segmente, uns fehlt also quasi ein viertes für unsere Zwecke. Aber auch das kann man lösen, indem wir einfach ein Pseudo-Segment nehmen. Da würde sich die PatchLevel (pl) Version anbieten, weil dass das einzige Versionssuffix ist, welches höher als die eigentliche Versionsnummer ist. Deine erste Version des Forks wäre dann quasi 2.2.15-pl1, meine Entfernung der Versionsprüfung stufen wir als 2.2.15-pl2 ein und deine darauf aufbauende Änderungen die du geplant hast, dann als 2.2.15-pl3. Nur als Beispiele. Diese Versionierung würde auch helfen den Überblick zu behalten, denn aktuell kann man beim Fork nicht wirklich erkennen, welche Version da installiert ist. Im ExtMgr sieht man nur 2.2.15, wie beim Original.
Diese beiden Eigenschaften hätten einen immensen Vorteil: wenn der Original Autor wieder die Arbeit an seiner Ext aufnimmt, könnten Benutzer (inklusive wir beide), die unseren Fork benutzt haben, problemlos auf die dann neue offizielle Version wechseln.
Sorry für diese wall-of-text, habe fertig!