Release-Zyklus und Long Term Support

[inyono]

Welche konkreten Vorteile habe ich von einem LTS? Bisher konnte ich keinen aus den bisherigen Beiträgen erkennen.

Ich sehe schon einen konkreten Vorteil. Was stelle ich mit Projekten an, die unter Contao 2.9.* entstanden sind? Wie schon mehrfach angemerkt wurde, ist ein Update von 2.9.5 auf 2.10 nicht ohne weiteres möglich, u.a. weil noch nicht alle Erweiterungen angepasst wurden. Dabei war das "lediglich" ein Minor-Release, bei einem Major-Release wäre die ganze Sache nochmal krasser.
Was mache ich jetzt, wenn in Contao eine Sicherheitslücke entdeckt wird? Contao 2.9.5 wird - so ist zumindest nach meiner Auffassung der jetzige Stand - kein Bug Fix erhalten. Was sagt man jetzt seinem Kunden? Ihre Seite hat ein Sicherheitsleck, ein Update geht aber nicht ohne weiteres? Finde ich persönlich jetzt nicht so die tolle Situation.
Bei einer LTS-Version hingegen könnte ich mir sicher sein, dass die Seite z.B. 2 Jahre lang ohne große Anpassungen "läuft". Neue Features interessieren mich bei einem fertigen Projekt, das einwandfrei funktioniert, ohnehin nicht.

Wenn ich das richtig sehe, sind momentan zwei "realistische" Möglichkeiten in der Diskussion:

1. Wir machen Contao *.* (z.B. 2.9.*) zur LTS-Version und portieren Bugfixes zusätzlich zur aktuellen Version (z.B. 2.10.*) auf diese LTS-Version für eine bestimmte Zeitdauer (z.B. 2 Jahre). Vor dem EOL dieser LTS-Version "küren" wir eine neue Version zur LTS. Vorteil: ich kann getrost bei einem Projekt die LTS-Version verwenden. Nachteil: Birgt die Gefahr, dass nur noch die LTS-Version genutzt wird.
2. Das jeweils letzte Minor-Release wird zur LTS und zwar bis zum nächsten Major-Release => EOL nicht fix. Vorteil: ich kann bei neuen Projekten die neue Version mit allen supertollen Features nutzen. Nachteil: Der eigentliche Vorteil ist mMn dahin, denn wenns blöd kommt, ist der LTS gar nicht so lang

Ich persönlich bevorzuge die erste Möglichkeit, wegen der bereits angesprochenen Planungssicherheit, just my two cents.

[andreas.schempp]

Das hätte auch zur Folge dass einzelne Agenturen bei einem neuen Projekt eine 1-jahr-alte Version von Contao einsetzen (wenn ein LTS 2 Jahre läuft). Damit läuft womöglich keine Erweiterung mehr, bzw. die müssten sich dem auch "unterwerfen".
Ich habe schon einige grössere Projekte gemacht, und wenn alles läuft werden da keine Patches eingebaut. Bei der einzigen Sicherheitslücke die ich von Contao kenne (Install-Tool) wurde ein Patch für ca. 3 Minor Versionen bereitgestellt.

Aus meiner Sicht gibt es (min.) 3 Arten von Projekten:

1. (Kleine) Agentur macht (kleine) Website für einen Kunden. Entweder macht der Kunde einen Update-Vertrag und erhält alle Updates, oder nach Abschluss passiert halt nichts mehr.
2. (Grössere) Agentur macht (grössere) Webseite für einen Kunden, ggf. mit Spezialentwicklungen. In Development/Staging Umgebung kann/wird ein Update gemacht und getestet.
3. Jemand (Agentur/privat) macht eine Webseite weil ihm Contao gefällt. Jedes mal wenn "Update verfügbar" ist wird auf Live-Update geklickt und gehofft das alles noch geht

Ich hab schon mehrere Installationen von Contao 2.5/2.6/2.7 auf 2.9+ gebracht, die einzigen Probleme habe ich wenn am Core "gepfuscht" wird. Das liegt auch am Kunden (der Contao nicht verstanden hat, z.B. Templates in den Modulordnern anpasst), aber das wird auch zwangsläufig so, wenn wir dazu anregen Patches selber einzubauen.


Anmerkung: Ich bin absolut einverstanden mit dem Major/Minor/Maintenance Zyklus, und im Maintenance nur Fixes zu machen. Ziel soll sein, dass ein Maintenance-Update gemacht werden kann ohne dass die Seite geprüft werden muss. Allerdings bin ich soweit wie möglich IMMER für Abwärtskompatibilität, auch bei Major-Versionen. Nicht die Microsoft-Version (DOS auf Win7), sondern die Apple-Version (ehemals Carbon für OS9, 2+ Jahre Rosetta für PowerPC). Nach angemessener Zeit kann dann damit gebrochen werden, es geht bei der Kompatibilität ja um die Erweiterungen...

[Dani]

Ich stimme andreas.schempp überall zu, ausser bei:

Allerdings bin ich soweit wie möglich IMMER für Abwärtskompatibilität, auch bei Major-Versionen.

Von mir aus könnten die zukünftigen Major-Versionen schon rückwärtskompatibel sein, doch zumindest bei Contao 3 sollte mal der "alte Ballast" weggeworfen werden.

[inyono]

Bei der einzigen Sicherheitslücke die ich von Contao kenne (Install-Tool) wurde ein Patch für ca. 3 Minor Versionen bereitgestellt.

Damit ist der Vorteil bzw. die Notwendigkeit einer LTS tatsächlich schnell dahin. Denn meiner Ansicht nach ist der Grund für eine LTS, dass man weiterhin mit Sicherheitsupdates versorgt wird. Wenn aber bei "kritischen" Sicherheitslücken Patches für mehrere Versionen angeboten werden, ist ja eigentlich alles super.

[hartlrobert]

Aus meiner Sicht ist das Problem bei 2.10, dass aufgrund der Versionsnummer kaum jemand mit so tiefgreifenden Änderungen gerechnet hat - und folglich überrascht und verärgert war, wenn die Seite danach "kaputt" war und Anpassungen vorgenommen werden mussten. Wenn dann "fehler anzeigen" gleich so viel anzeigt, dass man mit dem Scrollen nicht mehr fertig wird, hinterlässt das einen bleibenden Eindruck.

Das sollte so in meinen Augen so nicht mehr passieren. Das spricht für 3.0 statt 2.10. Wenn es dazu einen kurzen Guide gibt, was insb. am Template zu ändern ist, optimal (Beispiel die aktuelle meta robots-Umstellung).
Dass die Zahlen nicht nach oben hin ausufern, halte ich für sekundär. Dann heißt es eben Contao 12. Mein Gott. Das behandelt jedes System anders.

Wichtiger erscheint mir zunehmend die Konformität mit der wachsenden Anzahl an Erweiterungen. Bei Drupal kommen auch alle paar Jahre die großen Versionen. Aber man kann keine neue Version die folgenden 10, 12 Monate nutzen, da praktisch keine Erweiterung damit funktioniert. Manche Erweiterungen gibt es für 3 Hauptversionen in 3 Versionen mit 3fachen Ticket-Ebenen. Das sollte man vermeiden.

Ziel muss sein, dass eine größtmögliche Anzahl an Seiten das jeweils aktuelle System nutzt. Je einfacher und klarer, desto besser.

[backbone]

Was wären die wichtigeren Baustellen? Nicht falsch verstehen, ich sehe das genau so das es wichtigere gibt, aber bin jedoch der Meinung das man viele grundlegende Sachen nicht sauber hinbekommt ohnt die Abwärtskompatibilität zu brechen... und wenn LTS hier hilft mal eher dazu bereit zu sein die API etwas mehr zu ändern, dann seh ich das als sinnvoll an.

[Dani]

Was wären die wichtigeren Baustellen? Nicht falsch verstehen, ich sehe das genau so das es wichtigere gibt, aber bin jedoch der Meinung das man viele grundlegende Sachen nicht sauber hinbekommt ohnt die Abwärtskompatibilität zu brechen... und wenn LTS hier hilft mal eher dazu bereit zu sein die API etwas mehr zu ändern, dann seh ich das als sinnvoll an.

Genau, das sehe ich auch so.

[soweit_ok]

Welche konkreten Vorteile habe ich von einem LTS? Bisher konnte ich keinen aus den bisherigen Beiträgen erkennen.

Ein Vorteil könnte z. B. sein, solche Probleme nicht zu haben? http://www.contao-community.de/showt...766#post151766

[soweit_ok]

Aus meiner Sicht ist das Problem bei 2.10, dass aufgrund der Versionsnummer kaum jemand mit so tiefgreifenden Änderungen gerechnet hat - und folglich überrascht und verärgert war, wenn die Seite danach "kaputt" war und Anpassungen vorgenommen werden mussten. Wenn dann "fehler anzeigen" gleich so viel anzeigt, dass man mit dem Scrollen nicht mehr fertig wird, hinterlässt das einen bleibenden Eindruck.

Das sollte so in meinen Augen so nicht mehr passieren. Das spricht für 3.0 statt 2.10. Wenn es dazu einen kurzen Guide gibt, was insb. am Template zu ändern ist, optimal (Beispiel die aktuelle meta robots-Umstellung).
Dass die Zahlen nicht nach oben hin ausufern, halte ich für sekundär. Dann heißt es eben Contao 12. Mein Gott. Das behandelt jedes System anders.

Wichtiger erscheint mir zunehmend die Konformität mit der wachsenden Anzahl an Erweiterungen. Bei Drupal kommen auch alle paar Jahre die großen Versionen. Aber man kann keine neue Version die folgenden 10, 12 Monate nutzen, da praktisch keine Erweiterung damit funktioniert. Manche Erweiterungen gibt es für 3 Hauptversionen in 3 Versionen mit 3fachen Ticket-Ebenen. Das sollte man vermeiden.

Ziel muss sein, dass eine größtmögliche Anzahl an Seiten das jeweils aktuelle System nutzt. Je einfacher und klarer, desto besser.

Dieses Zitat lasse ich mal ungekürzt, weil ich es vollinhaltlich unterschreibe. Auch wenn die Versionsnummer dies nicht ausweist, ist die 2.10 wegen des Umstands, dass man viele auf 2.9 aufgesetzte Projekte nicht updaten kann, ohne dass ein erheblicher Teil nicht mehr funktioniert oder das Update zumindest einen ungewöhnlich hohen Zusatzaufwand produziert, für mich eindeutig ein Major Release. Deshalb finde ich Leo´s konstruktiven Vorschlag des LTS sehr gut. Damit trägt er dem sehr wichtigen Aspekt der Investitionssicherheit Rechnung.

Mein Eindruck ist, dass es zum Teil dieselben User sind, die bereits in der Planungsphase jegliche Bedenken bzgl. den der Unterstützung von HTML5 geschuldeten tiefgreifenden Änderungen (zu einem Zeitpunkt, zu dem HTML5 eigentlich noch kaum was bringt) abbügelten, nun auch noch den sehr vernünftigen Vorschlag zu LTS kaputt labern wollen. Obgleich einige der vorgebrachten Argumente durchaus richtig sind, macht mich das ziemlich ärgerlich. Wegen des Dilemmas, in das man gerät, wenn die eingesetzte, immerhin ebenfalls noch sehr neue Contao-Version kurzfristig plötzlich nicht mehr unterstützt wird, ein Update aber ebenfalls nicht möglich ist. Verdammt noch mal, so verbohrt kann man doch eigentlich garnicht sein, diese berechtigten Interessen nicht ernstzunehmen. Leider aber anscheinend doch, sonst bräuchte ich dies nicht schreiben.

[andreasisaak]

@soweit_ok

Sprich dich aus. Welche User meinst du?

[soweit_ok]

@jared

Ach was, jegliche Meinungsäußerung ist doch legitim, wozu sollte ich das nachträglich persönlich adressieren, wenn ich es nicht sofort tat. Darum ging es mir garnicht in dem Kommentar. Ich wollte lediglich dazu beitragen, dass sich ein Anti-Trend nicht alternativlos durchsetzt. Zudem sind fundiert vorgetragene auch kontroverse Ansichten produktiv, Kritik gilt also immer nur der Sache. Außerdem weiß ich, dass auch die Priorität möglichst dynamischen technischen Fortschritts das Contao-Projekt sehr voran bringt und bin auch selbst daran interessiert.

Mir ist auch klar, das LTS Ressourcen verbraucht. Doch das erachte ich als nötigen Kompromiss, damit Contao auch weiterhin gut für´s Business geeignet bleibt. Okay, hab ich vielleicht etwas scharf formuliert. ;-) Einfach weil mir daran lag, dass es nicht überlesen und darüber nachgedacht wird. Ich wünsche mir als Ergebnis der Diskussion die Verständigung auf eine Lösung des akuten Problems. Ob nun mittels LTS oder anders, ist mir egal. Hast Du denn einen konkret geeigneten Alternativvorschlag? Die Situation ist numal da und sie ignorieren hilft auch nicht weiter.

[BugBuster]

Wir sollten das hier nicht ständig in Verbindung mit den Problemen der 2.10 bringen.
Ich wette 90% der Hastig-Updater hätten das auch bei 3.0.0 getan.

Hier gehts um Sinn oder kein Sinn für Contao LTS anzubieten und in welcher Form.

Und dabei grüble ich grad, ob das denn den Kunden reicht, was ist mit den externen Erweiterungen?
Ich habe bei manchen Modulen für jede Minor Version von Contao auch eine eigene Modul Version.
(wegen der Nicht-Kompatibilität und keine Lust tausend Weichen einzubauen)

Theoretisch wäre es natürlich nun optimal (für die Nutzer) die passende Modulversion auch länger zu supporten.
Aber das wird wohl aus Zeitgründen schon nichts werden (bei mir).

[backbone]

Ich wünsche mir als Ergebnis der Diskussion die Verständigung auf eine Lösung des akuten Problems. Ob nun mittels LTS oder anders, ist mir egal. Hast Du denn einen konkret geeigneten Alternativvorschlag? Die Situation ist numal da und sie ignorieren hilft auch nicht weiter.

Was ist denn das akute Problem? Doch nicht das wir uns nicht auf ein LTS-System einigen können, sondern WAS bringt ein LTS System? Bisher war diese "Für was das Ganze?" sehr schwammig definiert... Genau das war doch die Frage von jared?

Aus meiner Sicht gibt es 2 Hauptgründe für ein LTS:
-> Aufräumarbeiten am Code werden ermöglicht, weil man die API "rücksichtsloser" brechen kann.
-> Firmen & Agenturen können darauf vertrauen das einmal aufgesetzte Seiten auch in den nächsten 2 Jahren noch "sicher" sind.

Letzteres kann man wirklich einfach mit sehr rudimentären Backports von Security Patches erreichen. Features werden nicht nachgerüstet, denn seien wir mal ehrlich: Wieviel Websiten werden mit Contao aufgesetzt die sich permanent weiterentwickeln (wollen). Das sind mMn. weniger als 5% der professionellen Projekte. Der Rest ist meist: Einmal Designen, einmal Programmieren (die gewünschten zusätzlichen Features), einmal Aufsetzen und einmal Initialpflege. Danach werden doch nur noch "laufende" Inhalte geschaffen die dem vorgegebenen Featurerahmen entsprechen.

Das Einzige was ärgerlich (aus Sicht der Betriebswirtler, Verkäufer, Agenturen) ist, wär ein grundlegendes Aufräumen der API, weil das geschätzt 99,9% aller Erweiterungen kickt, aber wenn man es richtig macht, ein einmaliges Event bleiben wird. Für die Zukunft find ich es aber unabdingbar. Schauen wir uns Theme+ an, das sind meiner Meinung nach Core-Features... das sind Dinge die einem massiv das erstellen von Websiten vereinfacht. Aber wir sind zur Zeit immer noch bei einer One-Man-Show was die Entwicklung betrifft. Alle anderen können nur zuarbeiten oder eigene verbesserte Mirrors der Core-Funktionen anbieten (welche aber mit vielen Kompromissen einhergehen, da man um fehlende/einschränkende Core-Funktionen herumarbeiten muss). Es ist klar das ein Einziger das System nicht auf zig verschiedenen Ebenen perfektionieren kann... das kann keiner. Was ich damit sagen will ist: Ein Aufräumen der API bringt bei dem aktuellen Entwicklungsmodell nicht soviel, ist aber zwingend notwendig.

[soweit_ok]

Und dabei grüble ich grad, ob das denn den Kunden reicht, was ist mit den externen Erweiterungen?

Eben weil man das nicht isoliert betrachten kann, ergibt sich das Problem in diesem Fall mit 2.10 auch ohne Hastig-Update. Da es in diesem Fall mit einem Major Release vergleichbare Auswirkungen hat, hab ich es so verstanden, dass es darum geht, vorerst auch noch bei 2.9 bleiben zu können, ohne den Support zu verlieren. Dass einige Erweiterungen nicht mehr supported werden, damit muss man mitunter auch bei der aktuellen Contao-Version leben, für die sie freigegeben sind. Okay, dann legt man entweder selbst Hand an oder verwirft diese Erweiterung. Den Core kann man aber nicht verwerfen und alle Auswirkungen eigenhändiger Modifikationen nicht so einfach zu überblicken.

Aus meiner Sicht gibt es 2 Hauptgründe für ein LTS:
-> Aufräumarbeiten am Code werden ermöglicht, weil man die API "rücksichtsloser" brechen kann.
-> Firmen & Agenturen können darauf vertrauen das einmal aufgesetzte Seiten auch in den nächsten 2 Jahren noch "sicher" sind.

Letzteres kann man wirklich einfach mit sehr rudimentären Backports von Security Patches erreichen. Features werden nicht nachgerüstet, denn seien wir mal ehrlich: Wieviel Websiten werden mit Contao aufgesetzt die sich permanent weiterentwickeln (wollen). Das sind mMn. weniger als 5% der professionellen Projekte. Der Rest ist meist: Einmal Designen, einmal Programmieren (die gewünschten zusätzlichen Features), einmal Aufsetzen und einmal Initialpflege. Danach werden doch nur noch "laufende" Inhalte geschaffen die dem vorgegebenen Featurerahmen entsprechen.

Ja, diese Gründe sind´s auch aus meiner Sicht. Es gibt allerdings nicht nur Agenturen und deren Kundenfirmen, sondern auch eigenständige professionelle Webseitenbetreiber, die auf Investitionssicherheit vertrauen können wollen. Die auch häufig ihre Seiten laufend weiterentwickeln. Spielt es eine Rolle, ob das vielleicht im unteren einstelligen Prozentbereich liegt? Bzw. sollten deshalb deren Interessen nicht ebenfalls angemessen berücksichtigt werden? Deckt sich rein zufällig mit meinen persönlichen Erwartungen. ;-)

Ich denke auch, Features sollten nicht nachgerüstet werden. Allein mit Security Patches ist es jedoch auch nicht unbedingt getan. Doch ich könnte bestens damit leben, würden auch ggf. bekannt gewordene fatale Bugs ebenfalls noch behoben werden - und weil selten, sicher auch vom Aufwand her vertretbar. Beispiel dafür ist zumindest ein Ticket dieser Kategorie, welches seit 2.9.2 bekannt und erst nach einem Jahr nur in der 2.10 erledigt ist.

[andreasisaak]

Aus meiner Sicht gibt es 2 Hauptgründe für ein LTS:
-> Aufräumarbeiten am Code werden ermöglicht, weil man die API "rücksichtsloser" brechen kann.
-> Firmen & Agenturen können darauf vertrauen das einmal aufgesetzte Seiten auch in den nächsten 2 Jahren noch "sicher" sind.

Für mich sind diese Gründe zurzeit mehr Selbstbetrug. Wenn unser Kunde mich nun fragt ob Contao denn nächstes Jahr noch da ist, dann kann ich ihm nur antworten "Das kann ich nicht garantieren". Wenn der LTS einführt wird, ist meine Antwort immer noch die selbe. Ein LTS kann das Problem der Ein-Mann-Entwicklung nicht lösen. Wenn Leo nächstes Jahr beispielsweise aus gesundheitlichen Gründen nicht mehr an Contao arbeiten kann, dann haben wir ein LTS für 2.9.5 - und kein Mensch wird erstmal Sicherheitsupdates pflegen.

Ein LTS ist also noch lange keine Garantie für ein langes und stabiles System.

Der 2te Punkt mit der API bereitet mir jetzt schon Bauchschmerzen. Wieviel willst du, @backbone, denn an der API ändern? Wir bauen zurzeit 100% des Codes der Erweiterung syncCto um. Wir waren doof und haben an der API vorbei gebaut. Wir wurden einmal deftig angepflaumt und jetzt sitzen wir seit über 300 Stunden daran das ganze neu zu programmieren und strickt an der API von Contao zu halten. Wenn ich dran denke das die API jetzt umgeschrieben wird und wir auch nur 50% ändern müssen, dann bekomme ich zuviel. Wer bezahlt uns diese Stunden? Das wäre der Tod für so manche freie Extension!

Ich bin nicht komplett gegen ein LTS, bitte versteht nur was ich damit ausdrücken will. Wie soll ein Mensch soviele Versionen supporten können? Wir melden doch nur Bugs, irgendeiner muss sie ja auch noch korrigieren. Und dann soll die API auch noch aufgeräumt werden? Wenn der LTS kommt, werde ich der letzte sein der es nicht schätzen weiß, die Probleme werden dadurch aber in keiner Form gelöst.

[andreas.schempp]

Noch eine Anmerkung, ich weis dass die einige/viele nicht hören wollen. TYPO3 hat für die Version 4.5 den LTS Support "ausgerufen". Das ist die erste LTS-Version bei TYPO3. Ich vermute dies hängt auch mit dem "drohenden" Update auf T3 5.0 zusammen. Seien wir ehrlich, Contao ist nicht TYPO3... wenn wir soweit sind, sollten wir darüber nachdenken.

[Toflar]

@jared: Das wird sich hoffentlich nicht verhindern lassen. Wäre dem nämlich so, würde das heissen, dass die API von Contao sich kaum verändern würde und wir sind uns ja alle einig, dass sie das über kurz oder lang muss. Die Programmiersprachen entwickeln sich ja auch weiter und wir sollten mitziehen, um Contao noch schneller und besser zu machen. Das sieht ja auch Leo so. An der Konferenz hat sich ergeben, dass es nicht Sinn macht, Contao von Grund auf neu zu schreiben und ein Refactoring angebrachter sei. Sprich: Die API muss und wird sich ohnehin verändern

Allerdings finde ich, dass wir immer mehr vom eigentlichen Thema abschweifen. Hier geht es ja nicht um die API sondern um den LTS.
Vielleicht sollte man zur API-Diskussion einen eigenen Thread eröffnen, damit die verschiedenen Pläne kundgetan werden können - allen Recht machen können wir es eh nicht. Das ist ja auch gut so, denn der Umgang mit der Weiterentwicklung eines Projekts ist mit ein Grund weshalb sich Leute für oder gegen eine bestimmte Software entscheiden.

Zurück zum LTS. Also ich befürworte die folgenden Ideen:

• Diejenige von Xtra: Einfach immer den letzten Minor-Release. Das heisst also die 3.1 kriegt solange LTS bis die 3.3 stable erscheint, dann wird nämlich die 3.2 automatisch zum LTS-Release.
• Diejenige von tril: Wir definieren einen LTS-Zeitraum, z.B. 2 Jahre und definieren immer 3 Monate vor Ablauf dieser 2 Jahre, welche Version der neue LTS-Release werden wird.

@Leo: Vielleicht magst die Ideen, die Du für realisierbar hältst, zusammenfassen und eine Umfrage daraus basteln? Einfach mit konkreten Versionierungsbeispielen, damit man sich auch was darunter vorstellen kann

@andreas.schempp: Mit Roadmap meinte ich eine Roadmap, nicht eine "welche Tickets kommen in der nächsten Version"-Übersicht, die wir aktuell haben. Ich hätte gerne was richtig Grosses - sowas:

1. HJ 2012 - Version 2.11

• Vereinigung von Benutzer/Mitglieder
• Extension Repository V3
• JS-Code auf Mootools 1.3 optimieren
• Auslagerung der localconfig, dcaconfig, langconfig, initconfig nach system/localconfig

2. HJ 2012 - Version 2.12

• Einführung eines VFS
• Auslagerung der Widgets nach system/widgets/frontend und system/widgets/backend in eigene Subordner
• Widgets vollständig Template-basiert machen

1. HJ 2013 - Version 3

• Überarbeitung des Frameworks/API
• Kapselung der Funktionen in themenbasierte Komponenten in system/components, die durch Drittentwickler dazugeladen werden können
• Einführung von Namespaces
• PDO oder aber Beschränkung auf MySQL
• Präfix "tl" abschaffen bzw. umbenennen

Ist natürlich weder komplett noch optimiert. Ist nur gerade was mir so in den Sinn gekommen ist und auch die Versionierung ist völlig fiktiv. Aber genau das ist es ja, es reden alle davon aber niemand weiss wann wir welches Thema denn angehen wollen.

[andreasisaak]

Damit ich das Thema API für mich abschließen kann: Ich meine nicht, das sich die API niemals verändern soll. Das die mit der Zeit gewachsen ist und einer Überarbeitung bedarf ist mir sehr wohl bewusst. Nur bitte nicht schon morgen sondern wie Toflar es in der fiktiven Roadmap erwähnt hat 2012/2013. Dann kann man planen, konzeptionieren und sich vorbereiten!!!

Das wärs für mich. Und da der LTS anscheinend schon beschlossene Sache ist werde ich auch zu dem Thema nichts mehr sagen ich füge mich der Mehrheit und hoffe das es klappt!

[tril]

Ein Vorteil könnte z. B. sein, solche Probleme nicht zu haben? http://www.contao-community.de/showt...766#post151766

Nein, weil es sich bei dem Problem nicht um ein Security Problem handelt. Bei LTS werden lediglich Security Patches oder Patches die vielleicht als "für den Betrieb allgemein kritisch" eingestuft werden gebackportet. Du magst dieses Problem vielleicht als kritisch einstufen, jedoch handelt es sich um einen Sonderfall, korrekt um eine allgemeine Performanceoptimierung die ich persönlich nicht unbedingt als kritisch einstufen würde. Also schlussendlich, LTS löst dieses Problem nicht.

Aus meiner Sicht gibt es 2 Hauptgründe für ein LTS:
-> Aufräumarbeiten am Code werden ermöglicht, weil man die API "rücksichtsloser" brechen kann.
-> Firmen & Agenturen können darauf vertrauen das einmal aufgesetzte Seiten auch in den nächsten 2 Jahren noch "sicher" sind.

jared hatte es bereits gesagt, erstes Argumente ist eher Augenwischerei als Realität.
Die "Aufräumarbeiten" wären doch auch nur dann möglich, wenn die Ext-Entwickler immer nur für die LTS entwickeln. Wenn Sie für die jeweils aktuellste Version entwickeln sind sie trotzdem betroffen. Es wird dadurch sogar noch schlimmer, weil die Agenturen dann fröhlich die Erweiterungen aktualisieren, die dann Plötzlich gar nicht mehr kompatibel zu einer LTS Version sind. LTS löst auch diese Problem nicht, es würde die Situation unter der Betrachtung "API Aufräumarbeiten" sogar verschlimmern!

Das zweite kann man nun sehen wie man will. Es bedingt trotzdem einer langfristigen Wartung. Ich mache lieber regelmäßig richtige Updates, bin dann pro Update vielleicht auch mal, wie bei 2.9 -> 2.10 etwas länger, also 1 bis 4 Stunden beschäftigt. Habe dann aber den Aufwand nicht "auf einmal", wenn es dann an den Relaunch geht. Denn ich weiß was der Kunde sagen wird "nehmen Sie die vorhandene Installation, wir wollen alle unsere Texte, Nachrichten, usw. behalten"!

Letzteres kann man wirklich einfach mit sehr rudimentären Backports von Security Patches erreichen.

Nein, ich habe es bei Avisota 1 und Avisota 2 gesehen, nach 1~2 Wochen lassen sich Backports noch relativ rudimentär backporten. Nach 3~6 Monaten sieht die Sache aber schon anders aus. Ein Großteil der Backports wird nicht mehr ein Backport sondern eine 50% Neuentwicklung des Patches sein. Wenn >1Jahr vergangen sind behaupte ich mal, dass die Chance einen Backport zu machen, ohne den Patch neu zu entwickeln stark gegen 0 tendiert! Abgesehen von eventuell bedingten Entwicklungen, die wieder weitreichendere Folgen haben.
Ich finde immer noch, das einige hier das Thema Backports von Sicherheitspatches viel zu locker sehen. Ich habe sowas schon selbst miterlebt, das ist alles andere als "mal eben so nebenbei gemacht"! Und da reden wir nicht von einem Community Projekt, sondern einer Software einer 30 Mann starken Firma, wo ich das miterlebt habe. Die Backport-Dauer lag in der Regel bei 80-90% der Zeit, die es gedauert hat, den Patch überhaupt zu entwickeln!

Features werden nicht nachgerüstet, denn seien wir mal ehrlich: Wieviel Websiten werden mit Contao aufgesetzt die sich permanent weiterentwickeln (wollen).

Das sind bei den Seiten die ich nach der Entwicklung weiterhin betreue 100%. Der Rest, den ich nicht mehr betreue macht grad mal 5% aus. Also aus meiner Sicht totales kontra zu deinem Beispiel.

Das Einzige was ärgerlich (aus Sicht der Betriebswirtler, Verkäufer, Agenturen) ist, wär ein grundlegendes Aufräumen der API, weil das geschätzt 99,9% aller Erweiterungen kickt, aber wenn man es richtig macht, ein einmaliges Event bleiben wird. Für die Zukunft find ich es aber unabdingbar. Schauen wir uns Theme+ an, das sind meiner Meinung nach Core-Features... das sind Dinge die einem massiv das erstellen von Websiten vereinfacht. Aber wir sind zur Zeit immer noch bei einer One-Man-Show was die Entwicklung betrifft. Alle anderen können nur zuarbeiten oder eigene verbesserte Mirrors der Core-Funktionen anbieten (welche aber mit vielen Kompromissen einhergehen, da man um fehlende/einschränkende Core-Funktionen herumarbeiten muss). Es ist klar das ein Einziger das System nicht auf zig verschiedenen Ebenen perfektionieren kann... das kann keiner.

Und da sind wir irgendwie wieder bei dem Thema, Core-Entwickler-Team

Was ich damit sagen will ist: Ein Aufräumen der API bringt bei dem aktuellen Entwicklungsmodell nicht soviel, ist aber zwingend notwendig.

Also doch ein Contao 3 mit rundum erneuerter API?

Noch eine Anmerkung, ich weis dass die einige/viele nicht hören wollen. TYPO3 hat für die Version 4.5 den LTS Support "ausgerufen". Das ist die erste LTS-Version bei TYPO3. Ich vermute dies hängt auch mit dem "drohenden" Update auf T3 5.0 zusammen. Seien wir ehrlich, Contao ist nicht TYPO3... wenn wir soweit sind, sollten wir darüber nachdenken.

100% Ack und das trifft auch auf andere, deutlich größere und stärkere Projekte zu als Contao!

[backbone]

@jared

Für mich sind diese Gründe zurzeit mehr Selbstbetrug. Wenn unser Kunde mich nun fragt ob Contao denn nächstes Jahr noch da ist, dann kann ich ihm nur antworten "Das kann ich nicht garantieren". Wenn der LTS einführt wird, ist meine Antwort immer noch die selbe. Ein LTS kann das Problem der Ein-Mann-Entwicklung nicht lösen. Wenn Leo nächstes Jahr beispielsweise aus gesundheitlichen Gründen nicht mehr an Contao arbeiten kann, dann haben wir ein LTS für 2.9.5 - und kein Mensch wird erstmal Sicherheitsupdates pflegen.

Ein LTS ist also noch lange keine Garantie für ein langes und stabiles System.

Du hast recht mit dem was du schreibst, garantieren kannst du nix, aber das kannst du bei einer, von einer Firma entwickelten, Software auch nicht. Ich hab aber auch nirgends was gegenteiliges behauptet. Ich sehe das nur nicht so eng wie du, denn wenn Leo wirklich aus irgendwelchen Gründen nicht mehr in der Lage sein sollte Contao weiterzuführen, fallen mir auf Anhieb Leute ein, die das weiterführen würden.
Es könnte auch morgen die Welt untergehen, gegenteiliges kannst du auch nicht garantieren :P
Man kann mit einer LTS aber die Wahrscheinlichkeiten positiv optimieren, denn es fallen die sicherheitstechnischen Gründe weg, die gegen einen Einsatz von Contao sprechen.

Der 2te Punkt mit der API bereitet mir jetzt schon Bauchschmerzen. Wieviel willst du, @backbone, denn an der API ändern? Wir bauen zurzeit 100% des Codes der Erweiterung syncCto um. Wir waren doof und haben an der API vorbei gebaut. Wir wurden einmal deftig angepflaumt und jetzt sitzen wir seit über 300 Stunden daran das ganze neu zu programmieren und strickt an der API von Contao zu halten. Wenn ich dran denke das die API jetzt umgeschrieben wird und wir auch nur 50% ändern müssen, dann bekomme ich zuviel. Wer bezahlt uns diese Stunden? Das wäre der Tod für so manche freie Extension!

Ich würd ziemlich viel ändern. In Hinsicht auf PHP 5.3 und eines eventuellen Einsatzes von Doctrine (DBAL und/oder ORM oder ähnliche Frameworks) sogar einen kompletten Rewrite anstreben. Deswegen gibt es LTS, wenn du (eigene) Erweiterungen hast auf die du angewiesen bist, die bisher aber noch nicht verfügbar sind, dann kannst du LTS benutzen. Natürlich wird das nicht von heut auf morgen passieren, doch grundlegende API/Core-Änderungen werden jetzt schon 1,5 Jahre vor sich hergeschoben und es wurde teilweise noch nicht mal Konzeption betrieben. Und das liegt wiederrum am Entwicklungsmodell, ich sehe natürlich das mit den aktuellen Releasezyklen eine Person an der Grenze ist.

Ich bin nicht komplett gegen ein LTS, bitte versteht nur was ich damit ausdrücken will. Wie soll ein Mensch soviele Versionen supporten können? Wir melden doch nur Bugs, irgendeiner muss sie ja auch noch korrigieren. Und dann soll die API auch noch aufgeräumt werden? Wenn der LTS kommt, werde ich der letzte sein der es nicht schätzen weiß, die Probleme werden dadurch aber in keiner Form gelöst.

Wir reden beim Vorschlag von tril, von genau 2 Versionen: Die Aktuelle und EINE LTS. Alle anderen Vorschläge, die mehr Versionen behinhalten, halte ich für nicht durchführbar.


@Toflar
Würde deine Roadmap sofort als Zukunftsgrundlage unterschreiben.


@tril

jared hatte es bereits gesagt, erstes Argumente ist eher Augenwischerei als Realität.
Die "Aufräumarbeiten" wären doch auch nur dann möglich, wenn die Ext-Entwickler immer nur für die LTS entwickeln. Wenn Sie für die jeweils aktuellste Version entwickeln sind sie trotzdem betroffen. Es wird dadurch sogar noch schlimmer, weil die Agenturen dann fröhlich die Erweiterungen aktualisieren, die dann Plötzlich gar nicht mehr kompatibel zu einer LTS Version sind. LTS löst auch diese Problem nicht, es würde die Situation unter der Betrachtung "API Aufräumarbeiten" sogar verschlimmern!

Jeder Entwickler kann für sich selber entscheiden, ob er gegen Trunk oder LTS entwicklen will. Aber für LTS wird doch fast automatisch eine Version bereitstehen? Meine Erweiterungen zB sind alle zu 2.9.5 kompatibel, einige muss ich aktualisieren, damit sie 2.10 fähig sind. Aber es gibt doch immer noch die 2.9er Versionen, die kann man verwenden. Keiner behauptet das LTS auch für Erweiterungen gilt, also muss ich die 2.9er Version meiner Ext auch nie wieder anfassen, wenn ich nicht will/keine Zeit habe.

Das zweite kann man nun sehen wie man will. Es bedingt trotzdem einer langfristigen Wartung. Ich mache lieber regelmäßig richtige Updates, bin dann pro Update vielleicht auch mal, wie bei 2.9 -> 2.10 etwas länger, also 1 bis 4 Stunden beschäftigt. Habe dann aber den Aufwand nicht "auf einmal", wenn es dann an den Relaunch geht. Denn ich weiß was der Kunde sagen wird "nehmen Sie die vorhandene Installation, wir wollen alle unsere Texte, Nachrichten, usw. behalten"!

Kommt auf die Art des Updates an... optimal wär: "Button drücken, fertig!", da würd ich auch 1000 mal am Tag updaten Aber sonst sehe ich das hier so wie du, allerdings hat das nix mit dem Backport von SecuPatches zu tun.

Nein, ich habe es bei Avisota 1 und Avisota 2 gesehen, nach 1~2 Wochen lassen sich Backports noch relativ rudimentär backporten. Nach 3~6 Monaten sieht die Sache aber schon anders aus. Ein Großteil der Backports wird nicht mehr ein Backport sondern eine 50% Neuentwicklung des Patches sein. Wenn >1Jahr vergangen sind behaupte ich mal, dass die Chance einen Backport zu machen, ohne den Patch neu zu entwickeln stark gegen 0 tendiert! Abgesehen von eventuell bedingten Entwicklungen, die wieder weitreichendere Folgen haben.
Ich finde immer noch, das einige hier das Thema Backports von Sicherheitspatches viel zu locker sehen. Ich habe sowas schon selbst miterlebt, das ist alles andere als "mal eben so nebenbei gemacht"! Und da reden wir nicht von einem Community Projekt, sondern einer Software einer 30 Mann starken Firma, wo ich das miterlebt habe. Die Backport-Dauer lag in der Regel bei 80-90% der Zeit, die es gedauert hat, den Patch überhaupt zu entwickeln!

Wieviele SecuPatch/Änderungen gabs in den letzten 24 Monaten? Eine Hand Voll? Ein Dutzend? Und das waren größenteils banalste Dinge. Hier würd ich Erfahrung > Worst-Case sehen...

Das sind bei den Seiten die ich nach der Entwicklung weiterhin betreue 100%. Der Rest, den ich nicht mehr betreue macht grad mal 5% aus. Also aus meiner Sicht totales kontra zu deinem Beispiel.

Du betreust zu 100% Websiten, an denen du mehr als einmal alle 2 Jahre, neue Erweiterungen installierst und neue Funktionen einbaust? Aber du hast ja schon selbst gesagt, dass du modifizierte Contao-Versionen verwendest, was dir sowieso Mehraufwand auflastet, bei nem Update. Und das wär doch eher was für LTS? Du kannst 2 Jahre lange gegen LTS entwickeln und dann, wenn nötig, in einem Rutsch auf Trunk oder nächste LTS updaten.



Zu den 2 Anderen Zitaten: Ja Core-Entwickler Team ist notwendig bevor man Hand an die API legt, ganz einfach um Ideen und Neuerung kritisch bewerten zu können auch mit "Veto-Optionen". Und ja ein Rewrite der API ist mMn. spätestens mit PHP5.3 notwendig.

[tril]

Jeder Entwickler kann für sich selber entscheiden, ob er gegen Trunk oder LTS entwicklen will. Aber für LTS wird doch fast automatisch eine Version bereitstehen? Meine Erweiterungen zB sind alle zu 2.9.5 kompatibel, einige muss ich aktualisieren, damit sie 2.10 fähig sind. Aber es gibt doch immer noch die 2.9er Versionen, die kann man verwenden. Keiner behauptet das LTS auch für Erweiterungen gilt, also muss ich die 2.9er Version meiner Ext auch nie wieder anfassen, wenn ich nicht will/keine Zeit habe.

Damit ist de fakto LTS wieder hinfällig, du darfst wenn du Contao als LTS verwendest keine Extension verwenden, die nicht selbst auch als LTS langfristig supportet. Ansonsten ist nämlich dieser Sicherheitsfaktor direkt wieder ausgehebelt weil die verwendeten Erweiterungen ein potentielles Risiko sind. Drupal bspw. backportend Sicherheitsupdates auch für unsupported modules, also Module die eigentlich nicht vom Drupal Projekt selber sind. Aber denen ist klar, eine LTS für das Kernprojekt macht keinen Sinn, wenn die Erweiterungen nicht auch Sicherheitsupdates erfahren.

Du betreust zu 100% Websiten, an denen du mehr als einmal alle 2 Jahre, neue Erweiterungen installierst und neue Funktionen einbaust? Aber du hast ja schon selbst gesagt, dass du modifizierte Contao-Versionen verwendest, was dir sowieso Mehraufwand auflastet, bei nem Update. Und das wär doch eher was für LTS?

Nicht wirklich, weil ich habe nur EINE modifizierte Contao Version und die nutze ich in allen Projekten. Ich habe also keinen Mehraufwand dadurch, die modifizierte Version erstelle ich so oder so, ich brauche sie ja für neue Projekte. Und ja, bei mir werden alle Installationen 1 mal im Monat aktualisiert, inkl. aller Erweiterungen. Diesen Monat habe ich es nur das Contao Update ausgelassen, weil viele Erweiterungen noch nicht 2.10 Kompatibel sind. Aber alle Installationen werden im laufe des Septembers bei mir auf Contao 2.10 gehen.

Zu den 2 Anderen Zitaten: Ja Core-Entwickler Team ist notwendig bevor man Hand an die API legt, ganz einfach um Ideen und Neuerung kritisch bewerten zu können auch mit "Veto-Optionen". Und ja ein Rewrite der API ist mMn. spätestens mit PHP5.3 notwendig.

Für eine Aktualisierung der API habe ich mich auch stehts ausgesprochen. Es gibt dafür aber nur 2 Wege:
1. Kompletter Rewrite (nach der Diskussion auf der ConKon wird es das aber gar nicht geben)
2. Sukzessive Entwicklung, mit langfristiger Backwards Kompatibilität. Und "Ausmisten" kann erst dann geschehen, wenn abzusehen ist, dass gar keine, bis verhältnismäßig wenig Extensions davon betroffen sind (also quasi alles was nicht gepflegt wird).

Und ganz ehrlich, so viele "Altlasten" die wirklich überflüssig sind sehe ich jetzt in der API noch nicht.

[backbone]

Damit ist de fakto LTS wieder hinfällig, du darfst wenn du Contao als LTS verwendest keine Extension verwenden, die nicht selbst auch als LTS langfristig supportet. Ansonsten ist nämlich dieser Sicherheitsfaktor direkt wieder ausgehebelt weil die verwendeten Erweiterungen ein potentielles Risiko sind. Drupal bspw. backportend Sicherheitsupdates auch für unsupported modules, also Module die eigentlich nicht vom Drupal Projekt selber sind. Aber denen ist klar, eine LTS für das Kernprojekt macht keinen Sinn, wenn die Erweiterungen nicht auch Sicherheitsupdates erfahren.

Also für viele Websiten würde das "Standard"-Contao ausreichen, wenn ein paar von den "Standard"-Erweiterungen in die einzelnen Core-Module integriert wären, ja. Das würde aber wieder ein breiteres Core-Team erfordern, da die Standard-Core-Module dann größer wären. Du siehst wir drehen uns hier im Kreis.

Nicht wirklich, weil ich habe nur EINE modifizierte Contao Version und die nutze ich in allen Projekten. Ich habe also keinen Mehraufwand dadurch, die modifizierte Version erstelle ich so oder so, ich brauche sie ja für neue Projekte. Und ja, bei mir werden alle Installationen 1 mal im Monat aktualisiert, inkl. aller Erweiterungen. Diesen Monat habe ich es nur das Contao Update ausgelassen, weil viele Erweiterungen noch nicht 2.10 Kompatibel sind. Aber alle Installationen werden im laufe des Septembers bei mir auf Contao 2.10 gehen.

Wir haben uns hier missverstanden. Ich meine nicht Websiten die Contao-Updates bekommen, sondern von Websiten die auf Contao-Update angewiesen sind, weil neue Funktionen gefordert sind, die nur in neuen Contao-Versionen möglich/schon vorhanden sind. Also ich kenn wenig Kunden die solche Update-Arbeiten bezahlen... viele Kunden wollen keine Wartungsverträge oder ähnliches.

Für eine Aktualisierung der API habe ich mich auch stehts ausgesprochen. Es gibt dafür aber nur 2 Wege:
1. Kompletter Rewrite (nach der Diskussion auf der ConKon wird es das aber gar nicht geben)
2. Sukzessive Entwicklung, mit langfristiger Backwards Kompatibilität. Und "Ausmisten" kann erst dann geschehen, wenn abzusehen ist, dass gar keine, bis verhältnismäßig wenig Extensions davon betroffen sind (also quasi alles was nicht gepflegt wird).

Und ganz ehrlich, so viele "Altlasten" die wirklich überflüssig sind sehe ich jetzt in der API noch nicht.

2. ist mMn. nicht möglich bzw. ist der Kosten/Nutzen-Effekt dermaßen gering...

[tril]

Also für viele Websiten würde das "Standard"-Contao ausreichen, wenn ein paar von den "Standard"-Erweiterungen in die einzelnen Core-Module integriert wären, ja. Das würde aber wieder ein breiteres Core-Team erfordern, da die Standard-Core-Module dann größer wären. Du siehst wir drehen uns hier im Kreis.

Würde theoretisch, wenn ich dann nicht die 3 Fache Zeit benötigen würde, wie wenn ich meine Erweiterungen nutze. Aber das hast du mit den "Standard"-Erweiterungen ja denke ich gemeint. Ich mein, man nehme mal Theme+, das ist selbst wenn man ohne externe Dateien Arbeitet eine Verbesserung des Verhaltens.
Ohne jetzt Leo schlecht reden zu wollen, ich habe mich auf den Hook für den Aggregator gefreut und musste dann enttäuscht feststellen, dass ich ihn für meinen Fall gar nicht gebrauchen kann. Das lag aber nicht an Leo, sondern daran das ich mich nicht drum gekümmert habe (weil ich zu dieser Zeit auch nicht die Zeit hatte)... als Ausenstehender Entwickler der sich die Informationen quasi "beschaffen" muss, ist das halt immer ein wenig schwierig.

Also ich kenn wenig Kunden die solche Update-Arbeiten bezahlen... viele Kunden wollen keine Wartungsverträge oder ähnliches.

Das ist alles eine Frage der Argumentation gegenüber dem Kunden. Wer bei mir oder korrekt, wer bei der Agentur für die ich die Webseiten betreue hosten will, bekommt das nur MIT Wartungsvertrag. Wenn sie nicht bei denen Hosten lassen möchten, dann müssen die sich auch selber kümmer. Außer die Installation und vielleicht Fehlerbeseitigung bei der Einrichtung auf den Kundenserver haben wir dann nichts mehr damit zu tun. Und das sind so ca. 5% aller Kunden.
Wobei die Agentur bei mir nur ca. 70% aller Website-Projekte ausmacht. Von daher dürfte die Rate bei mir doch höher liegen.

2. ist mMn. nicht möglich bzw. ist der Kosten/Nutzen-Effekt dermaßen gering...

Wieso? Der Kosten/Nutzen ist ziemlich hoch. Nehmen wir mal das Bsp. ORM. Nehmen wir an wir bauen Doctrine ein und bauen eine neue API. Dann bauen wir die vorhandene Database API so um, dass sie die bisher zur Verfügung gestellte Funktionalität auf Doctrine abbildet, sozusagen als Wrapper. Machen kannst du das durchaus und ist nicht sehr aufwendig. Man baut halt einfach "eine neue API Komponente". Mit der Einführung von Namespaces ist das sogar noch leichter. Wir haben ja schon oft gesagt, dass wir von dem Hierarchie-Mist weg wollen und wenn wir damit anfangen, ein Modulares System zu bauen, das Modulare parallel zu dem Vorhandenen aufbauen und die vorhandene API als Wrapper umbauen, verlieren wir mit wenig Aufwand kein bisschen Kompatibilität. Man kann es sogar noch so weit treiben, dass du die Wrapper mit einer deaktivierbaren Deprecated Meldung ausstattest. D.h. ein Entwickler kann Decprecated Meldungen aktivieren und seine Extension bequem auf die neue API umstellen. Aber seine alte Version läuft trotzdem noch "längere" Zeit weiter ohne das er sie anpacken muss. Also ich finde den Kosten/Nutzen-Effekt doch als ausgeglichen und Vorteilhaft.

[folkfreund]

Irgendwie gehen hier verschiedene Argumentationsstränge (verständlicherweise) durcheinander.
Ich möchte auf die Anfangsfrage zurückkommen und nochmal die Gründe für ein Release zusammenstellen:

1. es werden (sicherheitsrelevante) Fehler behoben
2. es werden neue Funktionen bereitgestellt, die alten Schnittstellen bleiben unverändert. Folglich sollten alte Erweiterungen weiter funktionieren, neue Optionen stehen aber zur Verfügung
3. es werden inkompatible Änderungen an der API vorgenommen, alte Erweiterungen werden möglicherweise nicht mehr funktionieren

Unter der Annahme, dass diese 3 Punkte jeweils klar voneinander zu trennen sind, lassen sich die Anforderungen der Anwender/Kunden vielleicht darauf abbilden:

• ein bestehendes Projekt soll mit geringem Aufwand aktuell gehalten werden. Dazu sind nur Updates der Kategorie 1. nötig.
• ein bestehendes Projekt soll mit vertretbarem Aufwand gepflegt und ggf. erweitert werden. Updates der Kategorien 1. und 2. decken diesen Fall weitgehend ab.
• Die Anforderungen eines Projektes können erst durch die neuesten Features erfüllt werden. Es ist also die Verwendung oder das Update auf das Release der kategorie 3. notwendig.

Worauf ich hinaus will: LTS ist v.a. für Situationen interessant, in denen keine oder nur geringe Erweiterungen eines fertigen Projekts geplant sind. Für ein neues Projekt will man nicht eine Version verwenden, deren Support schon bei Fertigstellung erlischt.
Solange Folgereleases zu den Kategorien 1 und 2 gehören, sind sie im Kontext eines LTS möglich. Darum muss meines Erachtens nicht eine spezielle Release zur LTS-Version erklärt werden. Die Aussage bezieht sich eher auf die API.

Das Hauptproblem bei der LTS-Planung liegt also in der Planung von Releases mit API-Änderungen. Nach einer inkompatiblen API-Änderung müssen die vorherigen API-Versionen, deren LTS noch läuft, bis zum Ende der vereinbarten LTS-Zeit weiter gepflegt werden. Um nicht mehrere parallele LTS-Versionen pflegen zu müssen folgen daraus:

• saubere Trennung zwischen den oben genannten Kategorien, also z.B. keine Fehlerkorrekturen und gleichzeitige API-Änderung für neue Features in einem Release
• inkompatible API-Änderungen nur in Zeitabständen ~ LTS-Zeitspanne

Ich kenne allerdings euren Entwicklungsprozess nicht genug, um zu beurteilen, ob diese Überlegungen tatsächlich zutreffen bzw. so umzusetzen sind. Es wäre beispielsweise denkbar den o.g. Kategorien Major, Minor und Revision in der Numerierung zuzuordnen.

Viele Grüße, folkfreund

[tril]

Solange Folgereleases zu den Kategorien 1 und 2 gehören, sind sie im Kontext eines LTS möglich.

Das Problem ist, du kannst Änderungen der Kategorie 2 nicht so ohne weiteres in ein LTS packen, da gehören die auch nicht hin. LTS bezieht sich immer nur auf Sicherheitsupdates und eventuell für den Betrieb kritische Bugfixes. Alle anderen Bugfixes stehen außen vor! Das ist das wesen einer LTS, ansonsten könntest du gar nicht garantieren, dass du problemlos ein LTS Release aktualisieren kannst. Bugfixes bedeuten nämlich auch immer Funktionsveränderung und ein LTS Release sollte keine Funktionsveränderung beinhalten, außer es ist zwangsläufig erforderlich. Ein Sicherheitsupdate ist typischerweise keine Funktionsveränderung, die Funktion bleibt vollständig erhalten.

Mit anderen Worten: LTS beinhaltet lediglich Änderungen der von dir aufgezählten Kategorie 1. Nicht aber der Kategorie 2 oder 3.

[soweit_ok]

Das Problem ist, du kannst Änderungen der Kategorie 2 nicht so ohne weiteres in ein LTS packen, da gehören die auch nicht hin. LTS bezieht sich immer nur auf Sicherheitsupdates und eventuell für den Betrieb kritische Bugfixes.

Hmmh, stimmt. Vielleicht war´s nur etwas unglücklich formuliert, der Rest des Beitrags scheint mir plausibel.

Aber was genau ist ein betriebskritischer Bugfix, wenn nicht gleich ganz Contao zusammenbricht bzw. nach welchen Kriterien wird die Gewichtung letztlich entschieden? Ich denke, das sollte möglichst eindeutig definiert werden, sich jedenfalls nicht an der Prozentzahl der betroffenen Webseiten orientieren oder nach Gutsherrenart entschieden werden. Betriebskritisch ist auch, was nur geschätzte 0,5 % der Contao-Webseiten betrifft. Oder angenommen, die Sympthome zeigen sich nur bei einer Extension, die Ursache läge aber im Core. Dann könnte man sagen, setzt doch diese Erweiterung nicht ein - weil es sich nicht in den Kernfunktionen auswirkt, ist das nicht Sache von Contao und dem LTS. Wenn´s aber eine der großen Extensions wäre, käme man so nicht aus der Nummer raus und betroffene Kunden würden mächtig sauergefahren.

Wahrscheinlich treten beide Situationen selten bis nie ein, denn schließlich werden kritische Bugs fürgewöhnlich auch ohne LTS gefixt oder es wird ein Workaround veröffentlicht. Schon allein, weil Contao einen Ruf zu verlieren hat. Kunden werden dem LTS aber wohl nur wirklich vertrauen, wenn der garantierte Umfang klar geregelt ist und sich nicht in Einschätzungen üben wollen, ob womöglich ausgerechnet ihr Projekt zum (für sie vielleicht sehr teuren) Grenzfall geraten könnte.

Vielleicht habe ich nicht supergeschickt ausgedrückt, was ich damit meine. Dass halt einfach "Ja/Nein" zu LTS nicht reicht und auch nicht die pauschale Aussage "nur Sicherheitsupdates und betriebskritische Bugs". Contao ist ein so vielschichtiges Gebilde, dass eine softwarespezifisch exaktere Abgrenzung aussagekräftiger und damit auch vertrauensbildender wäre als lediglich die allgemeingültige IT-Definition. Anders gesagt, man kann nach meinem Verständnis zumindest die großen Extensions nicht außen vor lassen, weil Ursache und Wirkung von Bugs im Gesamtwerk verzahnt auftreten können.

[tril]

Ein bisschen Aufklärung:

Security Bug: Ein Bug der die Sicherheit des Systems gefährdet, weil es bspw. für einen außenstehenden Möglich ist, sich unberechtigt Zugriff auf das System zu verschaffen. (eher selten)

Betriebskritischer Bug: Ein Bug, der nicht nur ein Fehlverhalten verursacht, sondern das System und die Integrität der darin befindlichen Daten gefährdet. Also ein Bug, der Daten entweder verfälscht oder zerstört. (absolut selten, aber bestes Beispiel ist der "leere localconfig.php" Bug)

Normaler Bug: Das Verhalten ist nicht so, wie es sein sollte. (regelmäßig)

Zu deinem Extension Beispiel, wenn es eine Extension gibt, die für eine Contao Version mit einem normalen Bug entwickelt wurde. Dann wird die Erweiterung vermutlich so mit dem Bug umgehen, dass er die Erweiterung nicht stört (Workaround in der Extension). Ist die Erweiterung für eine jüngere Contao Version, ohne diesen Fehler freigegeben und du versuchst die trotzdem einzusetzen und kannst es dann nicht wegen dem Bug in Contao, dann ist weder Contao, noch die Erweiterung schuld, sondern du, weil du versuchst hast die Erweiterung unter der inkompatiblen Version zu benutzen. Es liegt hier in der Verantwortung des Extension Entwicklers, die Kompatibilität zu prüfen, richtig festzuhalten und bei Bedarf einen Workaround zu bauen. Würdest du den Bug fixen, müsste der Entwickler der Erweiterung trotzdem erstmal die Kompatibilität prüfen und die Erweiterung für den Revision Release mit dem Bugfix freigeben. Eigentlich genau das gleiche wie jetzt, das hat nix mit LTS oder nicht LTS zu tun.

[soweit_ok]

Ja, das ist soweit klar. Doch darum ging es mir in dem Beitrag bzw. nicht um ein eigenes Verständnisproblem. Sondern um das, was Du mit Deiner Erwiderung darauf im Ansatz vorgelegt hast.

Nämlich den Vorschlag einer aus mehr als den Begriffen "Sicherheitsupdate" und "betriebskritische Softwarefehler" quasi contao-zertifizierten ähnlich detaillierten Definitionsvorlage inkl. eben solcher Fallbeispiele für eine einheitliche Darstellung von Contao-Projektdienstleistern ggü. ihren Kunden. Wenn also Dienstleister ihren Kunden zusichern, die für das Projekt eingesetzte Contao-Version steht unter LTS, wären so auch mögliche Missverständnisse zwischen allen Beteiligten weitgehend auszuschließen. Das könnte natürlich auch jeder Dienstleister für sich ausarbeiten. Aber auf diese Weise wäre es einheitlich und auch viel praktischer, weil es nur einmal gemacht werden bräuchte.

Ist halt so ne Idee aufgrund dessen, dass nach meiner Erinnerung in irgendeinem vorherigen Beitrag geschrieben stand, LTS sei neben der Sicherheit für Entwickler auch als vertrauensbildendes Merkmal für die Endkunden geeignet und das stimmt ja auch. Na ja, alles womit geworben werden kann, ist gut. Sollte aber möglichst nicht unterschiedlich interpretiert werden und jedem Kunden klar sein, dass es sich dabei nicht um eine Art Universalgarantie handelt.

[FloB]

Zunächst möchte ich einfach mal kurz diese Doku empfehlen: http://semver.org/

Ich würde gerne folgendes Vorgehen bei Contao sehen:
- API bleibt für alle Minor-Versionen stabil. Das heißt, dass ohne Anpassung Erweiterungen unter verschiedenen Minor-Versionen einer Major funktioniert, ohne, dass sich das Verhalten des Codes ändert ohne Fehler entstehen. Das heißt aber auch, dass z. B. neue optionale Parameter bei Methoden erlaubt sind (wenn die o. geg. Bedingungen eingehalten werden, also das Originalverhalten des Codes sich nicht verändert) oder sogar neue Methoden und Klassen eingeführt werden können. Allerdings sollten die Änderungen sich nur in kleinem Umfang bewegen und keine grundlegend neue Funktionalität eingeführt werden, sodass sich Erweiterungsentwickler nicht so sehr um neue Minor-Versionen kümmern müssen.
- Letztere Möglichkeit fällt bei Maintenance-Versionen weg (wenn es nicht sinnvoll vermieden werden kann). Also sind Maintenance-Versionen API-gefroren. Hier gibt es nur Sicherheits- und Stabilitätsupdates (auch krasse Fehlfunktionen sollen, wenn möglich, ausgebügelt werden).
- Major-Versionen können die API auch so ändern, dass die Funktionsweise von Code sich ändert und somit Erweiterungen geändert werden müssen.

Auf Basis dieses Vorgehens können wir über LTS diskutieren.

Aus Sicht des Anwenders ist innerhalb einer Major keine besondere Vorsicht bei Updates benötigt (soll zumindest). Aus Sicht der Erweiterungs-Entwickler könnte es aber durchaus erst ab einer bestimmten Minor möglich sein, eine Erweiterung ans Laufen zu bekommen (weil API-Funktionen fehlen). Um das zu umgehen, sollten mMn Erweiterungen nur im experimentellen Status für eine Major mit Minor-Bedingung freigegeben werden (die Erweiterung kann dann schon getestet werden), stabil und für den Einsatz empfohlen sind die Erweiterungen dann aber erst mit der nächsten Major!

Bei Maintenance muss ein Update mit einem Klick (und ohne automatische Anpassungsskripte) erledigt sein, und alles läuft – egal bei welcher Konfiguration – wie vorher (ausgenommen hochkritische Fehler, die eine tiefergehende Änderung benötigen, das ist aber sehr, sehr, sehr, sehr selten).

Eine neue Major kann größere Arbeit beim Update erfordern, bietet aber auch Möglichkeiten für weitergehende Änderungen (auch größere Template-Änderungen, nicht zu verwechseln mit Mini-Änderungen, z. B. hinzufügen von <span.active> in der Navigation).
Durch die strikteren Bedingungen für die Releases wäre eine neue Major pro Jahr angeraten (aber man sollte natürlich immer flexibel bleiben und sich nicht an einem Datum festbeißen).

Ein LTS sollte meiner Meinung nach für 2 Jahre gelten, für die jeweils stabile Minor (also 2.9 bis 2013 gefolgt von non-LTS 2.10, 3.x usw., dann 4.2-LTS bis 2015 gefolgt von 4.3, 4.4, 5.0 usw.). Ein LTS wird weiter mit Maintenance-Updates versorgt, und sonst nichts. Erweiterungen sollten für diese Versionen stabil sein, wenn sie eingesetzt werden. Wer neue Features einer Erweiterung (oder vom Core) benötigt, muss diese dann entweder selber backporten, oder zur nächsten Major (ggf. Minor) greifen. Zusätzlich sollte im ER die Möglichkeit eingerichtet werden, "alte" Versionen parallel zu den neuen anzubieten (quasi eine Möglichkeit für LTS für Erweiterungen zu bieten) – ja, man kann schon beliebige Versionen wählen, aber man kann als Entwickler nicht zwei Versionsstränge führen; und ja, nicht jeder will/wird das machen, aber das ist die Sache der Entwickler, und Möglichkeit sollte einfach geboten werden.


Ich find den Heiopei, der um große Versionssprünge gemacht wird, etwas übertrieben. Man kann sich ruhig trauen, in großen Versionen zu "landen". Ist doch egal?!

Ich hoffe, meine zwei Cent waren nicht zu verwirrend. Ich schlage mich mal weiter mit höherer Mathematik rum.

[SunBlack]

So, ich werf mich auch mal in die Diskussion .

LTS klingt prinzipiell gut, aber es gibt ja nicht nur Vorteile, sondern auch Nachteile. LTS klingt zwar gut, aber um ehrlich zu sein: Wie sieht die Supportlage momentan aus? Kunden die keinen Wartungsvertrag haben, werden wohl oftmals die Installation selber nicht updaten, da sie angst haben, das was Kaputt geht und sie es dann evtl. selber nicht fixen können. Kunden die einen Vertrag haben, ist es egal, ob eine LTS eingesetzt wird oder nicht, Hauptsache es läuft alles, wofür die Agentur verantwortlich ist. Aus Sicht der Agentur: LTS-Version leichter zu updaten, da wahrscheinlich keine Anpassung notwendig (kostengünstig). Aber auch bei der aktuellen Lage, ohne LTS-Versionen, sehe ich es nicht so schlimm, da Agentur die Entwicklung von Contao folgen und wissen was sich geändert hat. Die Umstellung von 2.9 auf 2.10 sollte von daher keine böse Überraschung darstellen, da tpl->xhtml5 groß angekündigt wurde (und bei meinen Webseiten die ich betreue, brauche ich selbst dafür nichts machen (nur benutzte Extensions abtesten halt)). Selbst bei größeren Anpassungen sollten den Agenturen in der Lage sein, eine Webseite relativ zügig auf eien neue Version zu aktualisisieren, denn wenn man dei Anpassung für mehrere Seiten macht, hat man dann schnell den Blick dafür, was gemacht werden muss. Und da normalerweise eh mind. 1 webseite in entwicklung ist, besteht die Arbeit da lokal bestimmt sowieso schon... Also ich (als au0enstehender), halte dies für vertretbar. Und aus Sicht der Entwickler: Für Leo bedeuted LTS mehr arbeit, die er nicht für andere Bugfixes nutzen kann. Für Extensionentwickler heißt das, sie müssen Addons jetzt nicht nur für die aktuelle Version entwickeln, sondern ggf. noch für eine ziemlich alte LTS-Version (Kostensteigerung). Also bisher sehe ich keinen richtigen Grund, eine LTS einzuführen.

Der Hauptgrund für eine LTS ist für mich, sind die Erweiterungen. Bei einer meiner Webseiten ist eine Erweiterungen z.B. noch nicht kompatibel zu 2.10 (bzw ich muss halt selber von tpl in xhtml umbenennen, aber egal). Wenn ich nun die fixes haben will, muss ich also warten, bis alle Ext. kompatibel sind. Eine LTS würde jetzt dafür sorgen, dass ich trotzdem Updates bekomme, ohne dass ich Angst um die Erweiterungen haben muss. Aber zu welchen Preis? Die Extensionentwickler wissen jetzt: es gibt eine LTS, auf die die Leute zugreifen können. Also kann ich mir mehr Zeit lassen beim aktualisieren der Erweiterung. Ergebnis, mehr veraltetet Extensions und somit weniger Gründe für die anderen, auf die neuste Version zu setzen.

Naja bevor ich komplett ins rumlabern verfalle : Ich bin gegen eine LTS, die für 2 Jahre oder so ausgelegt ist. Sie hat zwar seine Vorteile, aber ich finde, die Nachteile überwiegen.

Trotzdem bin ich für eine Art LTS, jedoch auf eine andere Art und Weise. Hintergrund ist die letzte Änderung des Release-Models. Beispiel: Man schlägt ein Feature vor, als Contao 2.9.1 rauskam (erschien am 09.08.2). Features werden erst in der nächsten großen Version geupdated, also 2.10. Also sagt man sich, ist kein wichtige Änderung, auf das Vierteljahr oder so wartest du, dann brauchste selber keine Erweiterung dafür schreiben. Nunja, wer jetzt mal auf den Kalender schaut sieht, dass ein Jahr von 2.9 auf 2.10 vergangen ist. Ergebnis ist, dass die Innovationskraft auf den Webseiten damit ausgebremst wird, da man sich halt ein bisschen mit darauf verlässt, dass eine Änderung demnächst vorgenommen wird. Wenn aber schnelle Innovationen erlaubt, haben die Ext.-Entwickler & Co den Nachteil, das sie mehr testen müssen. Des wegen gabs ja die Änderung.

Von daher schlage ich folgendes Model vor, die aus 2 Versioenn besteht.
- IV (Innovationsversion): D.h. in 2.10.0 kann es neue Features geben, aber auch in 2.10.1. Man muss also nicht mehr auf 2.11 warten. Neue Versionen hier im Monatsrythmus, unabhängig von Features, die es reingeschafft haben. Also ähnlich dem FF-Model, das fertige Features ausgeliefert werden.
- SLTS (Short-LTS^^). Nach ca. einem viertel Jahr (sollte weniger nach Features, als nach Zeit gehen), wird die aktuelle IV übernommen, mit all ihren Features, und nur noch mit Bugfixes versorgt werden, während es eine neue IV gibt (sprich Backport von nachfolgenden IV werden eingepflegt).

Da das ganze bestimmt wirr klingt (um die Zeit sollte ich keine Posts mehr schreiben, wo man nachdenken muss... ), ein fiktives Beispiel.
- 3.0.0 (Release 01/11, IV)
- 3.0.1 (Release 02/11, IV)
- 3.1.0 (Release 03/11, SLTS) <- alias 3.0.2, also die 3.0.2 IV wird zum SLTS erklärt. Am besten wäre ggf. die Version erst als 3.0.2 zu veröffentlichen und vlt. 2 Wochen danach zu 3.1.0 umzubennen (grund siehe weiter unten).
- 3.2.0 (Release 04/11, IV) <- neue IV, mit neuen Features
- 3.1.1 (Release 04/11, SLTS) <- Backport der wichtigsten Bugfixes von 3.2.0
- 3.2.1 (Release 05/11, IV) <- neue Features
- 3.1.2 (Release 05/11, SLTS) <- Backport der wichtigsten Bugfixes von 3.2.1
- 3.3.0 (Release 06/11, SLTS) <- alias 3.2.2, also die 3.2.2 IV wird zum SLTS erklärt

Oder anders ausgedrückt: IV ist 3.(2n).x und SLTS 3.(2n+1).x, wobei die SLTS halt immer die Bugfixes von der nachfolger IV erhält, sprich alle wichtigen Bugfixes von 3.(2n+2).x

Vorteil wäre: Wer auf ein feature wartet, bekommt es eher, muss dafür aber in Kauf nehmen, das für Bugfixes halt wieder eine IV nehmen muss, also evtl. mehr Updatearbeit hat, da zwischen den IVs halt mehrere Änderungen geben kann und somit auch mal Extensions nicht laufen.
Wer dagegen kein neues Feature braucht, nimmt die SLTS. Der bekommt somit nur Bugfixes und die Ext. laufen einfach weiter.
Vorteil für die Ext. Entwickler: Dadurch das eine SLTS halt keine LTS ist, sind Anpassungen halt kaum nötig, da die der Core sich in der kurzen Zeit nicht so krass weiterentwickeln kann, wie bei einer 2 Jahres LTS. Gleichzeitig können sie ihre Ext. an die IVs anpassen, so dass die Ext.-Entwickler halt etwas vorlauf bekommen. Im Optimalfall sind damit viele Erweiterungen auf die neue Version schon angepasst, so dass jemand beim Umsteig von einer SLTS auf die nächste große SLTS schon die Updates der Erweiterungen hat (des wegen auch die Verzögerung bei der Umbennenung).

Naja, ich glaube das klingt jetzt insgesamt wirklich wirr. Ich hoffe aber trotzdem, das die Grundidee rüberkommt, also man Innovationen schneller rausbringt, aber gleichzeitig den Ext.-Entwickler & Co zeit gibt, sich darauf anzupassen und in der Zeit der Anpassung trotzdem eine stabile Version zu haben.

PS: Warum ich die IV nicht mit der SVN-Version gleichsetze? Momentan bearbeitet Leo Tickets für die nächste größere Version erst dann, wenn diese als nächstes ansteht (meistens). Von daher bringt dies nichts. Abgesehen davon wäre die Anpassung der Erweiterungen weg, da es keine gemeinsame SVN-Rev.-Nummer gäbe, auf man sich einigen würde, die als Grundlage dienen soll.

Grundidee ist halt, dass halt beide Versionen produktiv eingesetzt werden. SLTS für die Updatefaulen und IV für die, die die neuen Features nutzen wollen (z.B. auch als Grundversion während der Neuentwickung, da man beim ausrufen einer I als SLTS ja einfach auf IV umsteigen kann).


PPS: Ich hoffe ich habe die Diskussion auch ein bisschen darauf gelengt, dass nicht nur LTS (keine neuen Features/große Änderung über langen Zeitraum) gewünscht ist, sondern auch das Gegenteil beachtet werden sollte.

PPPS: Ich gehe jetzt lieber schlafen, damit der Knoten nicht zusammenwächst

[Toflar]

Für mich kristallisiert sich aus der Diskussion so langsam folgende Feststellung heraus:

Wir brauchen eigentlich keinen LTS. Wenn der bestehende Release-Zyklus wie er anno 2009 beschrieben wurde (http://www.contao.org/blog-leser/ite...asezyklus.html) strikte eingehalten wird, so ergibt sich daraus eigentlich automatisch ein LTS.

• Major-Release (X.X.X): Fügt neue Features hinzu. Änderungen an der API ohne Beachtung der Rückwärtskompatibilität.
• Minor-Release (X.X.X): Fügt neue Features hinzu. Ändert aber niemals etwas an der API zu Lasten der Rückwärtskompatibilität
• Maintenance-Release (X.X.X): Behebt ausschliesslich Fehler des aktuellen Minor-Releases.

So. Damit ergibt sich eigentlich der LTS automatisch, denn man weiss, dass für alle Versionen der 2.X.X niemals etwas an der API geändert wurde. Die Erweiterungen werden also immer kompatibel bleiben.
Kommt jetzt irgendwie eine Sicherheitslücke ans Licht, so wird die einfach in einem neuen Maintenance-Release des aktuellen Minors behoben (fiktives Beispiel: Aktuelle Version 4.1.3, Version mit Security Patch: 4.1.4). Wer jetzt nicht von der 4.0.1 updated ist selbst schuld, weil kaputt gehen kann ja nichts. In der 4.1.0 wurden ausschliesslich Features ohne API-Changes hinzugefügt und alle Erweiterungen bleiben somit kompatibel.

Ok, was man an der Stelle jetzt diskutieren könnte, wäre ob man ein neues Maintenance-Release für die vorangehende Minor veröffentlichen möchte (also z.B. eine 3.2.9, wenn die letzte 3er-Version die 3.2.8 war).
Dann wäre das also dann ein LTS für die vorangehende Major-Version.

Das wäre m.M.n. die beste Lösung, bedingt aber, dass Leo den Release-Zyklus fix einhält (was er aber ja scheinbar jetzt auch vor hat ).
Ebenfalls bedingt es eine häufigere Veröffentlichung von Minor-Releases, damit Hooks etc. zeitnah implementiert werden (4x pro Jahr, also alle 3 Monate halte ich für sinnvoll) und ebenfalls häufigere Releases von Major-Versionen (1x pro Jahr API-Changes?).

[SunBlack]

Ich denke mal auch, dass das aktuelle Model eigentlich ganz gut ist.

Was man daran nur ändern könnte:
- Wenn nach z.B. v3.0.8 v3.1 veröffentlicht wird, das zeitgleich v3.0.9 veröffentlicht wird, wo nur Bugfixes enthalten sind, aber noch keine neuen Features. Damit haben Extensionentwickler halt ein Maintenance-Release Zeit ihre Erweiterungen auf die neue Version anzupassen. Danach aber keine weiteren Fixes mehr für 3.0.x, außer wenn wirklich ein Sicherheitsloch entdeckt wurde (sprich so wie beim Installtool, wo es dann für die letzten 3 Versionen ein Update gab).
- Minor-Release nicht danach veröffentlichen wann alle geplanten Features drin sind, sondern in etwa aller viertel Jahr (also nach 2-4 Monaten). Denn beim Übergang von 2.9 auf 2.10 hat mich wirklich die lange Wartezeit gestört.

[backbone]

Bei dem Vorschlag von Toflar würd ichs dann so halten:
Ca. einmal im Jahr kommt eine neue Major (oder so).

Security Patches werden immer für das aktuelle System angeboten und für die letzte Minor der letzten Major backportet.
Beispiel:

- Stand Contao 3.1.0
- Stand letzte Contao 2 stable: 2.10.4
- Security & Maintenance Release 3.1.1 erscheint
- Securityteil des Release wird zurückgeportet auf 2.10 als 2.10.5 (wenn gültig für alte Version)

[andreas.schempp]

Die Lösung von Toflar/wie beschrieben von backbone finde ich perfekt.

[Dani]

Ich auch!

[tril]

Die Lösung von Toflar/wie beschrieben von backbone finde ich perfekt.

+1

[Toflar]

Ja, das was backbone geschrieben hat, hab ich eigentlich bereits erwähnt:

Ok, was man an der Stelle jetzt diskutieren könnte, wäre ob man ein neues Maintenance-Release für die vorangehende Minor veröffentlichen möchte (also z.B. eine 3.2.9, wenn die letzte 3er-Version die 3.2.8 war).
Dann wäre das also dann ein LTS für die vorangehende Major-Version.

Sein "Security Patches" wäre halt dann das, was man in meiner Version als LTS angucken würde.

[folkfreund]

Hallo alle,

ich hatte es nicht so schön deutlich formuliert, aber auf ungefär so ein Modell wollte ich auch hinaus. War halt noch nicht zu Ende gedacht
Super!

Ok, was man an der Stelle jetzt diskutieren könnte, wäre ob man ein neues Maintenance-Release für die vorangehende Minor veröffentlichen möchte (also z.B. eine 3.2.9, wenn die letzte 3er-Version die 3.2.8 war).
Dann wäre das also dann ein LTS für die vorangehende Major-Version.

Organisatorisch heißt das: beim Übergang von 3.2.8 auf 4.0.1 werden zunächst die Fehler behoben (3.2.9) und dann die Erweiterungen inkl. API-Änderungen durchgeführt (4.0.1). Allerdings setzt das (wie weiter oben posutliert) die saubere Trennung der verschiedenen Änderungen voraus.

Was wir brauchen ist nicht ein Label 'LTS', sondern nachvollziehbare Kriterien, an denen sich Aufwand abschätzen lässt.

Vielen Dank für die tollen Diskussionsbeiträge!

folkfreund

[Toflar]

Organisatorisch heißt das: beim Übergang von 3.2.8 auf 4.0.1 werden zunächst die Fehler behoben (3.2.9) und dann die Erweiterungen inkl. API-Änderungen durchgeführt (4.0.1). Allerdings setzt das (wie weiter oben posutliert) die saubere Trennung der verschiedenen Änderungen voraus.

Nein. Wenn wir LTS für die jüngste Minor-Version der vorangehenden Major-Version anbieten wollen, heisst das, dass Fehler in der 3.* sowie der 4.* behoben werden. Der Benutzer der Version 3.* weiss also, dass er eine "bugfreie" Version und gegenüber der 4.* einfach weniger Features hat.

Beispiel:
LTS-Minor: 3.4
jüngstes Release der LTS-Minor: 3.4.12
Aktuelle Version: 4.2.3

Die Folge für Bugreports wäre also die Zuweisung zur Version 4.2.4 und 3.4.13 (sofern der Bugreport nicht ein Feature betrifft das erst in der 4.* hinzugekommen ist, natürlich).

Die Folge für Featurerequests wäre die Zuweisung zur 4.3.0.

Bei Veröffentlichung der 5.0.0 wird automatisch die 4.3 zum LTS-Minor und die 3.4 somit nicht länger unterstützt.

Verständlich?

[tril]

Korrekt muss man sagen, eigentlich ist nicht der letzte Minor, sondern der letzte Major ein LTS.

Wenn 5.0.0 raus kommt, wird 4.X.Y zur LTS. Da eine LTS aber nur noch Security Fixes beinhaltet, bleibt der Minor X natürlich immer gleich, aber die Revision Y ändert sich fortlaufend.
Wenn wie vorgeschlagen im Minor eine garantierte Abwärtskompatibilität vorhanden ist, dann kann man auch auf Minor Ebene aktualisieren, ohne Bedenken zu haben.


Das ganze löst aber ein anderes Problem nicht. Denn jetzt kann eine Agentur nicht mehr sagen, die Version 4.X.Y wird noch A Monate/B Jahre supportet. Weil wann die nächste Version 6 rauskommt steht dann nicht fest. Damit wäre dieser Supportzeitraum wieder undefiniert.