Auf dem Magento Stammtisch in diesem Monat (Oktober 2013, Berlin) wurde unter anderem wieder die recht schleppend verlaufende Entwicklung an Magento2 Thematisiert.
Meine Favoriten unter den dabei gefällten Urteilen sind "Da ändert sich ja gar nicht viel" und "wenn sie $something nicht auch gleich machen, können sie es auch gleich ganz lassen".

So gut diese Leute als Entwickler auch sein mögen, im Bereich des Projekt Managements halte ich sie für Unfähig.

Nun muss ich im vorraus sagen, ich habe absolut kein Wissen darüber wie die Entwicklung an Magento tatsächlich abläuft und wieso Dinge so entschieden und gemacht werden wie wir sie sehen. Jedoch lässt sich aus einigen Resultaten durchaus auf die Entscheidungen und Vorgänge Rückschluss ziehen.

Da das immer der meist erwähnte Punkt und gleichzeitig der Punkt ist der mich am wenigsten Interessiert, werde ich die Thematik über die lange Entwicklungszeit direkt zu Anfang behandeln. Das sind ein paar sehr simple Formeln.

• Entwickler können nur ein begrenztes Pensum an Arbeit bewältigen.
• Eine IT Firma hat für gewöhnlich nur eine beschränkte Zahl an Entwicklern
• EE + CE und 1.x + 2.x bedeuten dabei quasi 4 unterschiedliche Projekte syncron zu entwickeln.

Nun gibt es etwas, dass jede größere IT Abteilung kennen sollte, und zwar das $DINGE passieren. Zum Beispiel ein Release der einen schwerwiegenden Fehler enthält, der mehrere Wochen nacharbeit verursacht. Oder das mitten in der Umsetzung die Anforderungen geändert werden und man ein komplett anderes Framework nutzen muss. Oder das aufgrund einer verzögerten Entwicklung eines Releases, sich Patches für den vorhergehenden Release ansammeln und verarbeitet werden müssen.

Mehr möchte ich zu dem Thema dann auch nicht sagen.

Wir können uns nun gleich dem zuwenden, was ich eigentlich erzählen möchte. Vorher aber noch eine kleine Einführung, was semantische Versionierung ist. Beispiel: 1.7.2, oder auch x.y.z
Hier haben wir die Hauptversion(x) 1
den Feature Release(y) 7
den Bugfix Release(z) 2

Man unterscheidet hier, damit mögliche Unterschiede und Konsequenzen beim Versions wechsel direkt ersichtlich sind. Ein Bugfix Release zum Beispiel hat gar keine Risiken oder unterschiede zur vorhergehenden Version, er hat lediglich weniger Fehler. Ein Hauptrelease dagegen ist das genaue Gegenteil. Hier geht es geradezu darum Dinge kaputt zu machen, die in vorhergehenden Versionen funktionierten. Wenn man sich also fragt ob die aktuelle Änderung ein Haupt release sein sollte, stellt man sich am einfachsten die Frage wie viele Entwickler einen verfluchen werden, da sie nun all ihre Module anpassen müssen. Entgegen allgemeiner Meinungen sind Hauptreleases nicht dazu da neue Funktionen zu bringen. Meist ist sogar der Gegenteil der Fall und es gibt zunächst weniger Funktionen. Neue Funktionen kommen für gewöhnlich in den Feature Releases dazu. Vereinzelt werden Feature Releases auch dazu genutzt alte als depricated markierte Funktionalität zu entfernen oder zu ersätzen und auf zukünftige Haupt Releases vorzubereiten.

Damit sind wir dann auch endlich beim Thema. Welche Zielsetzung hat der 2.0 Release von Magento.

• Unittests einführen
• die Modul-, Ordner- und Datei-Struktur verändern
• ein neues Responsive fähiges default Theme einführen
• jQuery als primäres Javascript Framework einführen

später hinzu kamen dann noch

• Zend Framework in Version 2 nutzen
• strengerer gebrauch von Dependency Injection

Die Änderung an der Modul und Ordner Struktur ist dabei in meinen Augen die wichtigste, auch wenn sie von vielen nur belächelt wird. Sie erlaubt es uns nämlich Strukturell mit Zend Framework 2 und Symfony 2 gleichzuziehen. Was für viele nicht nachvollziehbar ist, wurde jenen die mit am Composer Magento Installer arbeiteten recht deutlich klar. Magento außerhalb seiner monolithischen Dateistruktur laufen lassen zu wollen, ist in Magento 1.x nur mit Workarounds und Einschränkungen möglich.