-
Also ich weiß ja nicht, welche Überlegungen die Entwickler angestellt haben wegen Contao 4.0. Wenn ich mir den Release-Plan anschaue, dann ist für mich zunächst mal eines auffällig. Es wird hier zum ersten Mal(?) - ich weiß nicht ob es das in der Geschichte von Contao schon mal gegeben hat, jedenfalls innerhalb des momentan veröffentlichten Release-Plans - dass zwei aktive Contao-Versionen gleichzeitig an den Start gehen werden. Normalerweise hätte ich erwartet, es kommt jetzt im Juni die 3.5 und dann im Dezember die 4.0. Offenbar ist also die 4.0 zeitlich vorgezogen worden.
Ich werte das einfach mal so, dass man hier praktisch erst mal ein paar Monate die Unmengen :D an neuer Technologie testet, damit die 4.1 dann wirklich guten Gewissens produktiv einsetzbar wird. Man hätte es vielleicht auch RC2 (oder RC3 oder was auch immer da käme) nennen können und die kommende 4.1 wäre dann die eigentliche 4.0 gewesen. Aber eine RC-Version würden dann vermutlich weniger Anwender einsetzen und somit auch testen als eine reguläre 4.0 :). Und auch die Zeit für die Tests und Bugfixes ist so mit 6 Monaten wesentlich länger als bei einem "normalen" Release Candidate.
Jedenfalls hat man mit der 3.5 LTS noch eine sehr lange Zeit die Möglichkeit, auch ohne Composer zu arbeiten. Inwieweit das auch mit 4.0 noch gehen wird, weiß ich nicht. Aber zumindest hat ja Spooky schon geschrieben, dass man Contao zumindest ohne Composer wird installieren können. Wobei mir wiederum unklar ist, ob das nur heißt "Ohne Composer in der Kommandozeile" oder "Contao 4.0 mit ER2 ohne Composer(-Client)". Für Kundenprojekte werde ich sicher zunächst eher die 3.5 LTS nutzen, die 4.0 eventuell für das eine oder andere private Funprojekt. Das schon aus rein praktischen Gründen (LTS ...), völlig unabhängig von der Frage Composer oder ER2.
-
Ich bin froh, dass Contao auf Composer aufbauen wird und dass dort einige Entwickler zig Stunden ihrer Zeit unentgeltlich investiert haben um Contao auf das nächste Level zu heben.
Composer hat sich zu dem de fakto Standard-Paket-Manager innerhalb des PHP-Kosmos' aufgeschwungen. Alle großen Bibliotheken, Frameworks usw. setzen schon darauf. Aus Entwicklersicht ist dies eine großartige Arbeitserleichterung. Man kann auf die Arbeit einer viel größeren Community zurückgreifen und darauf aufbauen. Für den Anwender bedeutet dies, dass Contao Erweiterungen (theoretisch) schneller entwickelt werden können, sicherer (da Komponenten breiter eingesetzt und getestet) werden. Ein Vorteil für beide Seiten.
Contao 4 benötigt von der Architektur Änderungen bei der Installation von Erweiterungen. Das ER2 wird somit nicht mehr funktionieren. Daher sehe ich es als richtige Entscheidung an, auf ein von der gesamten PHP-Community akzeptiertes Tool zu setzen, dessen Integration in Contao (technisch gesehen) seit Monaten funktioniert, anstatt weiter Zeit in eine Closed-Source-Insel-Lösung zu stecken, die fundamentale Probleme bei der Hauptaufgabe eines Paket-Managers hat. Das ER2 wurde seit Jahren, so wie ich das sehen kann, nicht mehr weiterentwickelt, da der eigentliche Entwickler seit Jahren nichts mehr mit Contao zu tun hat (https://contao.org/de/news/peter-koc...m-zurueck.html).
Klar gibt es bei so großen Umstellungen Probleme in der Übergangszeit. Ich bin aber froh, dass bei dem Composer Client erst einmal eine saubere technsiche Lösung im Vordergrund stand. Pakete inklusive aller Abhängigkeiten sauber zu installieren, ist das A und O von einem Paket-Manager. Dass nun auf der Basis eines soliden Fundaments an der Verbesserung der Benutzerfreundlichkeit usw. gearbeitet wird, ist dann der logische nächste Schritt. Anders herum wird das doch zur Katastrophe. Dass dies Zeit kostet ist klar, dass daran gearbeitet wird, schon vielfach erklärt.
Noch eine Randbemerkung zur Suchfunktion. Für mich war schon die Suche im ER2 unbrachbar, weshalb es auch Tools wie CERIS gibt. Google + das Forum waren für mich hier schon notwendig. Dadurch hat sich bei der Verwendung des Composer Clients nichts geändert.
