Contao-News

Wir informieren Dich hier regelmäßig zu Updates, stellen Best-Practice-Arbeiten vor und berichten über Aktuelles aus dem Contaoversum.

Änderungen im TYPOlight-Releasezyklus

von

Die vorzeitige Veröffentlichung der Version 2.6.5, die als eines der wenigen reinen Bugfix-Releases notwendig war, hat mal wieder ganz deutlich gezeigt, dass selbst Änderungen, die nur eine einzige Code-Zeile betreffen, weitreichende Folgen haben können.

Dabei war der Feature-Request an sich durchaus berechtigt. Es ging darum, die Dateinamen bei der Thumbnail-Erstellung zu erhalten, um das Suchmaschinen-Ranking positiv zu beeinflussen. Bei der Umsetzung habe ich jedoch vergessen, die Ordnerstruktur zu berücksichtigen, so dass jeder Dateiname theoretisch nur einmal hätte vorkommen dürfen - ein Fall, der in der Praxis wohl eher selten ist.

Mein eigentlicher Fehler lag aber nicht im Übersehen dieses Details, sondern darin, das Feature im Rahmen eines Maintenance-Release zu veröffentlichen. Ein Maintenance-Release dient - wie das Wort schon sagt - der Wartung des Systems, also der Behebung von Fehlern und nicht dem Hinzufügen neuer Features. Letzteres sollte ausschließlich bei Minor- und Major-Releases geschehen, denn diese können vor der Veröffentlichung als Beta-Version ausführlich getestet werden. Der Fehler wäre sicherlich in der Beta-Phase sofort aufgefallen.

Aus diesem Grund werden wir wieder zu dem alten und altbewährten Releasezyklus zurück kehren, der dem Projekt seit der ersten Veröffentlichung in 2006 zugrunde lag. Damals gab es wesentlich mehr Minor-Releases, die neue Features enthielten, und unregelmäßig - eben je nach Bedarf - Maintenance-Releases.

Ich hatte mich zwischenzeitlich überreden lassen, unregelmäßige Veröffentlichungen nach Möglichkeit zu vermeiden, damit Administratoren die Updates besser planen können. Der aktuelle Fall zeigt aber ganz klar, dass dieser Weg nicht der richtige ist. Maintenance-Releases müssen dann veröffentlicht werden, wenn sie notwendig sind, und nicht wenn es der Terminplan gerade erlaubt.

Zukünftig werden neue Features also nur noch im Rahmen von Minor- und Major-Releases mit vorheriger Beta-Version veröffentlicht. Damit trotzdem dieselbe Menge an Feature-Wünschen erfüllt werden kann, wird es wieder mehr als nur einen Minor-Release pro Jahr geben. Maintenance-Releases dienen dann nur noch der Fehlerbehebung und des "Feintunings" und werden nicht mehr regelmäßig alle 6 Wochen veröffentlicht, sondern nach Bedarf.

TYPOlight bietet mit dem Live Update eine hervorragende Möglichkeit, um Aktualisierungen schnell und unkompliziert durchzuführen, so dass theoretisch auch drei Veröffentlichungen innerhalb eines Monats ohne größeren Zeitaufwand bewältigt werden können. Wem das trotzdem zu viel Arbeit ist, dem empfehle ich, nur die Minor-Releases einzuspielen und die Maintenance-Releases weitestgehend außer Acht zu lassen - es sei denn, es handelt sich um einen Sicherheitsfix oder eine Installation ist direkt betroffen.

Zurück zur News-Übersicht.

Kommentare

Kommentar von Nina Gerling |

Das kann ich nur unterstützen. Die Priorität muss bei einem stabilen und sicheren System liegen.

Kommentar von simplex3 |

Ich schließe mich dem völlig an. Letztlich kommt das auch den Endkunden zugute.
Da nehme ich einen evtl. etwas höheren Update-Aufwand gerne hin.

Kommentar von Matthias Feist |

Wunderbar! Ich bin genau dieser Meinung!

Kommentar von Fabian Fauth |

Da hast Du auf jeden Fall auch meine vollste Unterstützung!

Kommentar von Cervus |

Kling gut. Vielleicht haben dann auch die vielen Modulentwickler die Chance Schritt zu halten und ihre Module auf Kompatibilität hin zu prüfen. Dies kann man bei den kurzen Release- Zyklen nicht erwarten :-)

Kommentar von Leo Feyer |

Der Kommentar von Cervus ist ein weiteres Argument für den neuen Release-Zyklus. Denn wenn Maintenance-Releases zukünftig keine Features mehr beinhalten, dann ist auch die Modul-Kompatibilität gegeben. Module für die Version 2.7.0 funktionieren dann auch mit der 2.7.4 und der 2.7.29. Erst mit der Version 2.8 muss man sich wieder Gedanken darüber machen.

Kommentar von Helmut Schottmüller |

Hi Leo,
ich denke, das ist eine gute Entscheidung. Ein TL-Update ist ja nun nicht sehr kompliziert. Ich weiß nur nicht, ob ich das mit den Modulen so hundertprozentig unterschreiben kann. Es kann ja durchaus mal sein, dass man ein Modul auch bei einem Maintenance Release überarbeiten muss (so z.B. bei der vorletzten Änderung, als du an der iefixes.css etwas geändert hast. Das oxygen-Theme musste ich dann natürlich anpassen, damit die gefixte CSS-Datei auch darin verfügbar ist). Aber das ist ein Aufwand, der hinnehmbar ist.

Kommentar von Yanick Witschi |

Ich finde, dass wie auch immer man es macht, hat alles seine Vor- und Nachteile! Bei dieser Änderung überwiegen aus meiner Sicht die Vorteile und deshalb unterstütze ich diese Entscheidung voll und ganz.

Kommentar von Martin Heggli |

*phu*
und ich hab hier eine Testinstallation auf einem externen Server (quasi ein 1:1 Test) und bin fast nicht mehr nachgekommen mit updaten... :-) Für den Test-Server verwende ich (noch) keine Liveupdate-ID - daher habe ich mir gedacht, ihr wollt mit dem neuen Rythmus uns diese schmackhaft machen *grins*
An dieser Stelle wiedermal herzlichen Dank für das tolle System! :-)

Kommentar von manela |

Ich finde die Strategie auch richtig. Für meine Testumgebung habe ich mir jetzt extra eine Liveupdate-ID geholt. Damit warte ich meine Musterinstallation, die ich jeweils für die Kunden umbaue und dann rausgebe. Wenn die dann Wartung haben wollen, wird eine separate Liveupdate-ID dafür gekauft. Fair für alle Beteiligten und easy bei der Durchführung des Updates. Wer noch Update-Dateien mit der Hand einspielt, hat nach meiner Ansicht zuviel Zeit oder nur 5 € Taschengeld in der Woche. Das ist dann wirklich was anderes.

Kommentar von Thomas |

Ich hatte diesen Beitrag noch gar nicht gelesen. Aber ich stimme zu. Sicherheit geht vor, und die Minor Releases reichen mir eigentlich. Vielen Dank für Typolight, tolles CMS.

Einen Kommentar schreiben

Bitte rechnen Sie 6 plus 2.