[TYPO3-german] +1 / -1 Thread

Jan-Hendrik jh2011 at ivi-solutions.com
Sun Jan 27 10:30:23 CET 2013


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



More information about the TYPO3-german mailing list