DANKE CHRISTIAN!
Wollte Euch schon einen Tip geben, quasi für ein offizielles Core-Statement.
Bei der Gelegenheit: Danke für die viele (ehrenamtliche) Arbeit!!! Ich
bin gespannt auf die nächsten vielen Jahre des TYPO3CMS :-)
Grüße, Jan-Hendrik
Am 27.01.13 02:22, schrieb Christian Kuhn:
Moin.
Disclaimer: Eigene Meinung, ich spreche hier nicht offiziell als core
member.
On 01/25/2013 07:24 PM, Jan Kornblum wrote:
Was ich nicht verstehe, warum dann überall davon geredet wird, dass
pibase ab 6.0 bzw. 6.x nicht mehr funktioniert und "alle Extensions neu
geschrieben werden müssen". Wo liegt hier (mein) Mißverständnis bzw. das
der anderen?
Wer sagt das?
pibase wird nicht gedropt soweit wir in die Zukunft sehen koennen. Das
daraus resultierende Codemuesli einer nicht trivialen Extension ist zwar
schlimm, der Core waere aber mindestens zum jetzigen Zeitpunkt ganz
schoen bescheuert, wenn er sich mutwillig 90% aller TER Extensions
kaputt machen wuerde. Die pibase Basisklasse heisst vielleicht zwar
jetzt FrontendController statt pibase, der alte Name funktioniert aber
weiter.
Es gibt genau zwei Stellen die in 6.0 mutwillig brechen:
* Wie ueblich sind diverse ganz furchtbar vergammelte Core-Methoden
geloescht worden, die meisten davon sind seit 4.5 oder laenger als
veraltet markiert, der kleinere Rest seit 4.6.
* Alle XCLASS'es brechen, die Anmeldung hat sich geandert. Waehrend der
6.0 Entwicklung gab es zwar zwischendurch eine Kompatibilitaetsschicht,
die war aber so zielunsicher und hat soviel Performance gefressen, das
die wieder gedropt wurde. Es ist trotzdem moeglich, eine Extension mit
Xclasses parallel fuer 4.5 und 6.0 kompatibel zu machen. Da Xclasses
sowieso schon immer einfach mal so auch bei Minor Releases brechen
koennen, und das auch schon immer offiziell genau so kommuniziert wurde,
wurde die fehlende Kompatibilitaetsschicht an genau dieser Stelle in
Kauf genommen.
Ansonsten muessen Extensionentwickler gelegentlich mal die
Kompatibilitaet Ihrer Extensions checken, den deprecation Log lesen und
Wartungsarbeiten durchfuehren. Der Core *muss* das gelegentlich
forcieren, damit er sich ueberhaupt weiterentwickeln kann. Eine nicht
gewartete Extension mit der letzten Version aus 2009 ist dann halt im
Zweifel kaputt ... aber wer will eine Extension nutzen deren Entwickler
keine Fehler mehr loesen?
Ich habe diese Woche in einer Extension, die ich 1 Jahr nicht angefasst
habe, 4.3 und 4.4 Support gedropt und 6.0 Funktionalitaet verifiziert.
In keiner der core Versionen von 4.5 bis 6.0 wirft diese Extension
deprecation Fehler. Inklusive Release hat mich das effektiv zwei Stunden
gekostet.
Der 6.0er Core bringt die mit weitem Abstand groessten Codeaenderungen
in der Geschichte des Projektes. Die Umstellung auf Namespaces ist ein
Quantensprung in Hinsicht auf Lesbarkeit und logischen Aufbau und
vereinfacht den Einstieg in das Projekt erheblich.
Die Kompatibilitaetsschicht ist so gut, das sogar die seit Jahren
praktisch nicht gewartete und ausgesprochen umfangreiche Extension
tt_news noch relativ gut funktioniert. Als Alternative hat Georg es
locker und nebenbei hingekriegt, seine news Extension kompatibel fuer
4.5 bis 6.0 zu machen. Sein Kompatibilaetscode ist in einer Helferklasse
gekapselt, die sich zum Rueberkopieren in eigene Extensions geradezu
anbiedert.
templavoila hat ein paar kleinere Anpassungen im Backend gebraucht, weil
die Extension mit seinem 8 Jahre alten Code im Backend Modul teilweise
furchtbaren Mist baut, den heute kein vernuenftiger Mensch mehr so
zusammentackern wuerde.
Zwar wird der Core die "nicht namespaced" Klassen irgendwann loeschen
(hoffentlich fuer 6.2, weil die LTS Maintenance sonst ernsthaft
dauerhaft keinen Spass machen wird), es gibt aber bereits jetzt diverse
Ansaetze, auch dann noch 10 Jahre alten Extensioncode zu unterstuetzen.
Insgesamt sehe ich die Agenturaufgabe alte Instanzen zu warten recht
entspannt. Ich schaetze mal grob, bei uns ist der Aufwand fuer ein major
core ugrade ca. um den Faktor 40 kleiner als der initiale Aufwand fuer
den Launch eines Projektes. Kunden, denen man das nach 3 Jahren fuer den
Sprung von einer LTS auf die Naechste nicht als Notwendigkeit verkaufen
kann, will man schlicht nicht haben, weil die im Umkehrschluss
vermutlich auch sonst nicht alle Tassen im Schrank haben.
Ich durfte kuerzlich von 3.7 auf 4.5 updaten (nein, keine Instanz von
uns). Eine nicht ganz triviale Instanz, aber auch nicht wirklich gross.
Mit subversion einrichten, Upgrade, finalem Switch auf utf-8 in der
Datenbank, Testing, Cleanup, Dokumentation, Controlling, Kommunikation
und Rollout war das nach nem Personentag gelaufen. An dem Ding war seit
6 Jahren oder so nichts im Code passiert.
Hat einer von Euch mal versucht ein Bestandsprojekt von drupal 5 auf 7
zu ziehen? Oder ein Magento-Update nach 4 Jahren?
Im Fazit kann sich TYPO3 definitiv nicht vorwerfen lassen
Kompatibilitaet zu vernaechlaessigen.
Im Gegenteil macht sich der Core soviele Gedanken um
Rueckwaertskompatibilitaet, das dabei teilweise Agilitaet und
Weiterentwicklung auf der Strecke bleiben.
Gruesse
Christian
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
