Bevor demnächst Leben in die Repositories kommt, sollten wir noch ein paar Altlasten bereinigen. So hatten wir anfänglich die Branch-Benennung nach der OXID-Versionierung beibehalten (z.B. b-7.0.x). Wir sollten hier konsequenterweise besser die O3-Versionierung verwenden b-1…). Welche Art der Branches haltet ihr für besser:
für jede Major-Version einen separaten Branch (b-1.x, b-2.x, …)
So ist die Historie eines jeden Majors gut nachvollziehbar. Gibt es jedoch nachträglich ein Patch zu einem vergangenen Minor, kann das nur ein einem abgeleiteten Branch passieren.
für jede Minor-Version einen separaten Branch (b-1.0.x, b-1.1.x, b-2.0.x, …)
Die Struktur erlaubt das saubere Fortführen eines jeden Minors bis zum letzten Patch. Es können dann jedoch eine Menge Branches werden (Unübersichtlichkeit).
Ich freue mich auf eure Meinungen.
Die Umbauarbeiten habe ich für die kommende Woche geplant.
In diesem Atemzug werde ich auch das Repo “shop_ce” konsequenterweise nach “shop-ce” umbenennen. Beachtet dies bitte, wenn ihr einen Checkout davon vorhaltet.
Before the repositories come to life soon, we should clean up a few old problems. For example, we initially kept the branch naming according to the OXID versioning (e.g. b-7.0.x). Consequently, we should better use the O3 versioning b-1…). What kind of branches do you think is better:
A separate branch for each major version (b-1.x, b-2.x, …).
This way, the history of each major can be easily traced. However, if there is a subsequent patch for a past minor, this can only happen in a derived branch.
A separate branch for each minor version (b-1.0.x, b-1.1.x, b-2.0.x, …).
The structure allows the clean continuation of each minor until the last patch. However, it can then become a lot of branches (confusion).
I am looking forward to your opinions.
I have planned the rebuilding work for the coming week.
In the same process I will also rename the repo “shop_ce” to “shop-ce”. Please keep this in mind if you have a checkout of it.
Würde für jede Minor-Version einen eigenen Branch bevorzugen.
Das Thema Versionierung würde ich es gut finden, ein Bewusstsein für mehr Aktualität seiner Shop-Version zu schaffen.
Dort wäre ein Ansatz eine Long-Term-Support (LTS) Philosophie zu verfolgen, dass z.B. Major-Versionen immer 2-5 Jahren unterstützt. Dort müsste man gucken welcher Zeitraum am meisten Sinn ergibt.
Aber so das man von Kommunikation sicher sein, dass in dem LTS Zeitraum immer eine neue Major Version veröffentlicht und man diese in Anspruch nehmen sollte.
5 Jahre LTS-Support sind in dieser schnelllebigen Branche eine Herausforderung. Dem Grundgedanken stimme ich soweit zu.
Was dem in die Karten spielen könnte, ist eine meiner Überlegungen:
Eine Schwierigkeit bei OX sehe ich darin, dass selbst kleine Patches fest an die Compilation gekoppelt sind. Patches sind nur mit einem vollumfänglichen Shopupdate installierbar. Mit allen anderen Paketen, die da noch dran hängen.
Mein Wunsch für O3 wäre, dass Patches grundsätzlich auch ohne ausdrückliche Shopupdates installiert werden können (implizite Updates nur mit “composer update”). Damit wären innerhalb des Support-Zeitraumes auch ältere Installationen möglichst einfach auf einen sicheren Stand zu bringen. Natürlich alles im Rahmen der technischen Möglichkeiten.
Die Bedingung dafür ist das strikte Einhalten von Semantic Versioning. Das sollte aber zu leisten sein.
Die Verwendung von Composer lädt dazu ein immer mehr fremde Abhängigkeiten zu laden, statt Logik Bestandteile selber zu programmieren.
Gedanklich könnte man zum Vorgänger vor der 6er Serie zurück gehen wo es noch kein vendor Verzeichnis mit über 20.000 Dateien gab.
Die 5 Jahre LTS-Support werden aus der Abhängigkeitsstruktur gegenüber anderer Software-Bibliotheken nicht möglich sein z.B. Symfony Components welche laut LTS glaube maximal 3 Jahre supported werden.
When creating a framework, following the MVC pattern is not the right goal. The main goal should be the Separation of Concerns ; this is probably the only design pattern that you should really care about.
Ich hatte es unter dem Thread Gebt uns doch bitte Feedback - #18 by indianer3c bereits erwähnt, dass ungewöhnlich ist das OXID nicht den Symfony Kernel nutzt und es schön wäre diesen nachträglich zu integrieren.
Aber man könnte genauso gut in die andere Richtung gehen, dass man sich bewusst versucht vom Symfony Components zu lösen und diese noch spärlicher einzusetzen. Dies könnte nach Kaizen eine kontinuierliche angestrebte Verbesserung darstellen - wieder mehr in Eigenleistung umzusetzen.
Wir sollten aber auch die Benefits externer Bibliotheken nicht ignorieren:
Unter Beachtung bestimmter Qualitätskriterien können externe Bibliotheken besser entwickelt, fehlerfreier und umfangreicher getestet sein. Durch den häufigen Einsatz fallen Bugs viel eher auf, als in Software, die nur wenige Installationen hat.
Klar, man begibt sich auch in die Abhängigkeit der Autoren. Andererseits hängt man in der Abhängigkeit des eigenen Könnens und dem Fehlen der kritischen Masse.
Daher lege ich für mich bei der Auswahl externer Abhängigkeiten einige Kriterien fest:
ausreichende Installationszahlen
getesteter Code (UnitTests etc.)
aktuelle Pflege
Issues und PRs werden bearbeitet
ausreichende Komplexität der Bibliotheken
Und damit fällt bei umfangreichen Bibliotheken wie den Symfony-Komponenten die Wahl recht eindeutig. Ich würde mir auch als routinierter Entwickler nicht zutrauen, so was mal schnell selbst zu entwickeln.