Release-Zyklus und Long Term Support

[leo]

Nach der regen Diskussion darüber, ob die Version 2.10 nicht lieber als Conto 3 veröffentlicht werden sollte, und der daraus erkennbaren Unzufriedenheit mit dem jetzigen Release-Zyklus, denke ich momentan über alternative Release-Zyklen und mögliche "Long Term Support"-Releases nach. Hierzu würde ich gerne von euch hören, welche Erwartungen ihr an einen Release-Zyklus habt.

Klar ist, dass wir uns wieder mehr an die Änderungen im Release-Zyklus halten sollten, die wir bereits in 2009 beschlossen haben. Dies betrifft vor allem neue Features in Maintenance-Versionen. Zudem wollen wir wieder mehr Major-Releases (Contao 3, 4, 5 etc.) veröffentlichen; denkbar wäre z.B. alle zwei Jahre auf der Contao-Konferenz oder evtl. sogar jährlich.

Sollten wir uns für "Long Term Support"-Releases entscheiden, macht es eurer Meinung nach mehr Sinn

• die jeweils neue Major-Version zu nehmen (also z.B. Contao 3.0 für 18 Monate zu supporten, obwohl währenddessen schon 3.1, 3.2, 3.8 etc. erscheinen) oder
• die jeweils letzte Minor-Version des vorherigen Zweiges (also z.B. Contao 2.11 mit dem Erscheinen von Contao 3.0 noch 18 Monate lang als LTS-Release zu supporten)?

[Birden]

Ich halte dieses mit Chrom eingeführte, jetzt auch bei Firefox, angewandte rennen um … 3, 4, 5,6,7 etc. nicht für Gut, und fände es Schade wenn Contoa auf diesen Zug aufspränge.

[BugBuster]

Na Contao wird das ja nicht wie FF im Monatsrhythmus tun.
Ich finde alle 2 Jahre wenn es denn größere Änderungen sind reicht völlig für eine neue Major Release.

Was würde denn LTS Support in der letzten Vor-Version (2.11.x bei 3.0.0) denn im Detail bedeuten?
Nur Bugfixe oder auch kleinere Features (Minor Updates)?

[FloB]

Letzte Minor länger unterstützen, dafür häufiger den Major wechseln. Also jetzt wäre es bei 2.9 und 3.0 (die jetzt als 2.10 veröffentlicht wurde) angebracht gewesen!

[xtra]

Es geht hier nicht um "wir wollen moeglichst schnell viele Majors raushauen" sondern darum, wie o.g. etwa 2jaehrige Release zyklen mit neuen Majors zu etablieren und weiterhin, wie lange die Vorversion (sofern denn yberhaupt) weiter gepflegt werden soll.
Diese LTS Pflege ist lediglich ein Backporten von Bugfixes aus neuen Versionen in die vorherige. Im Endeffekt also eine Feature complete Version mit periodischen Fehlerbehebungen.

Es hat nichts damit zu tun etwa alles halbe Jahr ein Contao 4800 usw. zu releasen.

Meiner Meinung nach is ein LTS sehr wynschenswert, erfordert jedoch auch entsprechenden Aufwand. Bei den Tickets, beim Implementieren usw.
Ein Ticket muss somit naemlich mehreren Versionen zugewiesen werden bzw. auf alle moeglichen Versionen, die noch supported sind, repliziert werden.

Auf Kundenseite entsteht durch einen LTS eine Sicherheit, dass mit der neuen Version die alte noch weitergepflegt wird und man so die Upgrades in aller Ruhe testen und implementieren kann und parallel weiterhin mit Fehlerbehebungen versorgt wird.

Was ich mir bei diesen LTS Versionen jedoch gut vorstellen kann ist, dass man bugfixes zeitnaher released etwa als hotfixe neben einem komplett paket.
am BSP 2.9.5:
2.9.5.lts-hotfix1: Fehlerbehebung ticket #0815 - Patches Config.php et al. for localconfig.php overwrite error.
2.9.5.lts-hotfix2: Fehlerbehebung ticket #2305 - Patches The core to respect search order in Module XY
2.9.5.lts-hotfix3: Fehlerbehebung ticket #4224 - I don't know anymore what this is but it has definately something to do with the the question of life the universe and everything
etc.
Diese koennten dann direkt vom Kunden auf ihre Seiten eingespielt werden um am Puls der Zeit zu bleiben.
Nach obigem Beispiel koennte man auch noch 2.9.5.lts1-full pakete anbieten, welche dann an die Stelle der Maintenance Versionen treten, aber das wird dann eher auf quartalsweise/halbjaehrliche releases rauslaufen myssen wegen dem overhead (upload bei sf.net etc.).

Abschliessend: LTS Ja.
Welche Version: jeweils der letzte Minor.
2.9.5 => LTS
2.10.0 => release
(halbes?) Jahr Zyklus
2.10.X => LTS
2.11.0 => release
...
(24 Monate)
2.14.X => LTS
3.0.0 => release

[MacKP]

Ich kann Xtra da in jedem Punkt zustimmen.
Vor allem für wird das für Contao ein weiterer Pluspunkt den man bewerben kann. Das ganze bringt vor allem auch für große Seiten eine enorme Sicherheit!

Und das versteckte 2.9.5 = lts würde ich auch extrem begrüßen.
Gerade Seiten die man bisher erstellt hat, haben nicht unbedingt viele Gründe auf 2.10 zu gehen (die neuen Features brauch man nicht unbedingt). Und da wäre es schön, wenn die Seiten erst einmal sicher weiterlaufen könnten :-)

Viele Grüße

[BugBuster]

Der Zyklus von Xtra gefällt mir.

[xtra]

Abschliessend noch als Anmerkung, dass man bei jedem Minor Release ein EOL fyr den vorletzten Minor ausrufen sollte.
Dies koennte der Core als Standard im Backend ausgeben. Anstelle "Version X.Y.Z verfuegbar" koennte ab Release 2.11 in allen 2.9.5 dann: "Warning! 2.9.5 has reached EOL and will not be supported anymore" erscheinen, ansonsten erscheint lediglich der bisherige Hinweis.

[lindesbs]

Eigentlich gibt es dazu nichts mehr zu sagen.

Ausser, das eben nur Bugs und keine Features in den LTS Versionen bearbeitet werden.

+1

[Toflar]

Bin definitiv auch dafür! Ebenso bin ich für die Einführung einer EOL-Konstante. Allerdings weiss ich nicht ob die Idee mit der Benennung der Hotfixes gut ist, weil ich mir denken kann, dass das diverse Benutzer abschrecken könnte (wir wissen ja wie viele Leo's Ankündigung vollständig lesen...). Was wäre so falsch an einer 2.10.46?

Also die aktuelle Version in den trunk und die Versionen die noch LTS kriegen als branches weiterführen. Wobei ich mich frage ob 2 Jahre nicht etwas gar lang sind...das wären ja beim aktuellen Rhythmus ca. 4 Minor-Versionen

[BugBuster]

Abschliessend noch als Anmerkung, dass man bei jedem Minor Release ein EOL fyr den vorletzten Minor ausrufen sollte.
Dies koennte der Core als Standard im Backend ausgeben.

Gute Idee. Ich hatte mir auch überlegt wie das gehen soll, da es ja keine festen Termine gibt, hätte man sonst mehrere LTS unterwegs, wäre ja blöd.

[RainerG]

Aufgrund der grundlegenen Erweiterungen/Änderungen, die Contao 2.10 erfahren hat und den Umstand, dass (fast?) alle Erweiterungen angepasst werden müssen, hätte diese Version schon die 3 vor dem Punkt verdient gehabt. Auch aus der Sicht wenn man hier schaut, dass viele all zu sorglos auf 2.10 geupdatet haben.

Einen Versionssprung unbedingt an bestimmte Zeitzyklen zu klemmen halte ich für nicht unbedingt sinnvoll.

[BugBuster]

Auch aus der Sicht wenn man hier schaut, dass viele all zu sorglos auf 2.10 geupdatet haben.

Das hätten die auch bei 3.0.0 getan....

Einen Versionssprung unbedingt an bestimmte Zeitzyklen zu klemmen halte ich für nicht unbedingt sinnvoll.

Das wollte ich damit auch nicht sagen.
Ich hatte nur gegrübelt, wenn man eine Version als LTS labelt, woher weiß man, wann die aufhört. Aber Xtra hat dazu ja Lösungen gezeigt.

[dieselboy]

Aufgrund der grundlegenen Erweiterungen/Änderungen, die Contao 2.10 erfahren hat und den Umstand, dass (fast?) alle Erweiterungen angepasst werden müssen, hätte diese Version schon die 3 vor dem Punkt verdient gehabt. Auch aus der Sicht wenn man hier schaut, dass viele all zu sorglos auf 2.10 geupdatet haben.

Einen Versionssprung unbedingt an bestimmte Zeitzyklen zu klemmen halte ich für nicht unbedingt sinnvoll.

Dem kann ich nur zustimmen!

[leo]

Zusammengefasst heißt das also:

• Alle zwei Jahre eine neue Major-Version (evtl. auch jährlich, je nach Umfang der Änderungen)
• Mit dem Erscheinen einer Major-Version wird der letzte Minor-Release der Vorversion zum LTS-Release
• LTS-Releases werden bis zum EOL mit Bugfixes versorgt (= nur Maintenance-Releases ohne neue Features)
• Minor-Releases werden weiterhin dann veröffentlicht, wenn sie fertig sind, jedoch maximal 4 Stück pro Jahr
• Maintenance-Releases (Bugfix-Releases) werden weiterhin nach Bedarf veröffentlicht

Für Maintenance-Releases gilt zukünftig folgendes:

• Es werden ausschließlich Bugs behoben (keine neuen Features)
• Die API wird nicht verändert, also z.B. keine DCA-Änderungen und auch keine neuen Hooks
• Die Anzahl der Releases ist nicht limitiert
• Es gibt für Bugfix-Releases weiterhin keine Beta-/RC-Phase (Vorabankündigung mit kurzer Testphase wie gehabt)

Einen LTS-Support für jedes Minor-Release halte ich für zu aufwändig, daher ist das Erscheinen einer neuen Minor-Version (stable) gleichzeitig das EOL für die vorhergegangene Minor-Version.

[tril]

Gute Idee. Ich hatte mir auch überlegt wie das gehen soll, da es ja keine festen Termine gibt, hätte man sonst mehrere LTS unterwegs, wäre ja blöd.

Naja, man könnte auch eine statische Datei auf contao.org bereitstellen, die den Supportzustand einzelner Versionen festlegt, z.B.
contao.org/versions.ini:

2.10.0 supported
2.9.5 lts supported

Sobald die 2.10.1 raus kommt, sieht das dann so aus:

2.10.1 supported
2.9.5 lts supported

und bei der 2.11.0 so:

2.11.0 supported
2.10.4 lts supported

Alle ungenannten Versionen sind automatisch EOL.
(Die Versionsnummer sind jetzt einfach frei erfunden und stehen nicht im Zusammenhang mit meinen folgenden Erläuterungen )

Allerdings weiss ich nicht ob die Idee mit der Benennung der Hotfixes gut ist, weil ich mir denken kann, dass das diverse Benutzer abschrecken könnte (wir wissen ja wie viele Leo's Ankündigung vollständig lesen...). Was wäre so falsch an einer 2.10.46?

Warum nicht eine 2.9.5.46 ?
Die meisten Projekte sprechen eine LTS immer der Minor Version zu, nicht der Major Version. Also um auf Leo's eigentlich Frage zurück zu kommen, ein LTS gehört zur Minor Version nicht zur Major Version oder gar zur Release Version. Damit löst sich das Problem dann automatisch, weil jeder Hotfix eine eigene Release Version bekommt. Hotfixes ala Microsoft sind imo ein viel zu großer Verwaltungsaufwand, weil dann auch Abhängigkeiten oder Konflikte zwischen Hotfixes berücksichtigt werden müssten. Warum nicht also einfach Bugfixes so wie bisher als Releases weiter führen?

Aber immer den letzten Minor Release als LTS zu nehmen, ist einfach zu viel oder zu kurz, wenn man den vorherigen LTS dann fallen lässt. Schaut euch mal um, bei anderen Projekten, mir ist kein Projekt bekannt, dass mehr als eine einzige LTS Version hat! xtra hat es schon gesagt, aber xtra's LTS Zeitraum liegt dann ca. bei einem halben, bis ein Jahr.
Ich denke die Aussage "immer der letzte Minor" ist nicht zielführend, ich möchte als Beispiel einfach mal die Versionen von ubuntu auflisten:
- 8.04 LTS
- 8.10
- 9.04
- 9.10
- 10.04 LTS
- 10.10
- 11.04
https://wiki.ubuntu.com/LTS

Mir ist klar, dass die Versionsnummern an Jahr und Monat orientiert sind, aber genau deshalb zeigen Sie eines deutlich, im LTS Zeitraum von 2 Jahren gibt es immer nur eine einzige LTS Version! Welche Versionsnummer letztlich die LTS ist, ist den Nutzern egal. Daher finde ich sollte man es nicht von vorne herein so strikt machen.
Angenommen wir setzen die 2.9.5 als LTS, was ist in 2 Jahren? Sind wir dann bei Contao 4.0? oder vielleicht sogar noch bei Contao 3.6? Da es keine auf 2 Jahre ausgelegt Roadmap gibt, kann man das denke ich einfach nicht im Vorfeld sagen, Cononical hingegen kann darüber eine Aussage treffen, weil Sie feste Release Zyklen haben. Doch sie können keine Aussage darüber treffen, welchen "Inhalt" diese Version haben wird.

Und soweit ich den Releasezyklus und Leo's aussage verstanden habe, wird es zwar mehr Major und Minor Releases geben, aber in nicht fest definierten Abständen.
Deshalb mein Vorschlag: Nach Ablauf des LTS Zeitraum von 2 Jahren, wird die dann aktuell stabilste Version zur neuen LTS.

Also die aktuelle Version in den trunk und die Versionen die noch LTS kriegen als branches weiterführen. Wobei ich mich frage ob 2 Jahre nicht etwas gar lang sind...das wären ja beim aktuellen Rhythmus ca. 4 Minor-Versionen

Ich denke, 2 Jahre ist ok, auch wenn ich persönlich kein LTS Freund bin. Aber die meisten Web Projekte die nicht kontinuierlich gewartet werden, werden im Zyklus von ca. 2 Jahren überarbeitet. Daher denke ich ist 2 Jahre schon ok.

[christian]

... keine neuen Hooks ...

Die würde ich vielleicht nicht ausschließen. Sonst <thumbup>!

Grüße,

Christian

[xtra]

und auch keine neuen Hooks

Die würde ich vielleicht nicht ausschließen. Sonst <thumbup>!

Ich auch nicht.

[leo]

Zum Thema Hooks: Ich verstehe, dass es wichtig ist, dass Hooks möglichst schnell verfügbar sind. Allerdings würde das schon die erste Aufweichung der sonst so strikten Abgrenzung bedeuten und das würde ich gerne vermeiden. Wie wäre es, wenn wir zu jedem Hook eine Patch-Datei bereitstellen, so dass die Änderungen bei Bedarf einfach vorab in Kundeninstallationen übernommen werden können?

Zum Thema "die letzte Minor-Version mit LTS": Ich sehe ein, dass das schlecht kalkulierbar ist, weil man vorher nicht sagen kann, ob es tatsächlich die letzte Minor-Version eines Branches ist oder ob doch noch mal eine kommt. Andererseits finde ich es auch seltsam, wenn man sagt, dass die 2.9 ein LTS-Release ist und danach kommen aber noch die 2.10 und die 2.11. Von welchen Faktoren hängt es dann ab, welche Minor-Version ein LTS-Release wird?

[tril]

Zum Thema Hooks: Ich verstehe, dass es wichtig ist, dass Hooks möglichst schnell verfügbar sind. Allerdings würde das schon die erste Aufweichung der sonst so strikten Abgrenzung bedeuten und das würde ich gerne vermeiden. Wie wäre es, wenn wir zu jedem Hook eine Patch-Datei bereitstellen, so dass die Änderungen bei Bedarf einfach vorab in Kundeninstallationen übernommen werden können?

Über dieses Thema habe ich mit einigen Leuten auf der ConKon gesprochen und ich glaube man kann durchaus sagen das 25% bis 50% sowieso eine modifizierte Contao Version benutzen. Von daher +1 für diesen Vorschlag!

Zum Thema "die letzte Minor-Version mit LTS": Ich sehe ein, dass das schlecht kalkulierbar ist, weil man vorher nicht sagen kann, ob es tatsächlich die letzte Minor-Version eines Branches ist oder ob doch noch mal eine kommt. Andererseits finde ich es auch seltsam, wenn man sagt, dass die 2.9 ein LTS-Release ist und danach kommen aber noch die 2.10 und die 2.11. Von welchen Faktoren hängt es dann ab, welche Minor-Version ein LTS-Release wird?

afaik wird es nicht an der Version, sondern an dem LTS Zeitraum festgemacht. Wenn der LTS Zeitraum abläuft, muss man dann entscheiden, was die nächste LTS Version wird. In der Regel ist dies sogar noch nicht mal eine aktuelle fertige Version, sondern eine Version die erst in Kürze veröffentlicht wird.
Gehen wir also davon aus, Contao 2.9 wird zum 1. September 2011 zur LTS mit 2 Jahre Support.
Dann sind wir gegen Anfang September 2013 z.B. bei Contao 4.2, dann wird diese Version automatisch zur nächsten LTS. LTS richten sich imo nicht nach Features, sondern noch Support-Zeiträumen.
Man könnte auch von vorne herein sagen, die LTS wird zwischen 2 und 2,5 Jahren supported. Dann hat man noch bis zu 6 Monate Zeit, sich über die neue LTS Version "zu streiten" Für Unternehmen ist es aber trotzdem planbar.

[backbone]

Finde den Vorschlag von tril besser, das verhindert, dass man mehrere LTS-Versionen hat. Würde den Zeitraum nur nicht sooo festnageln... Also anstatt "LTS ist 2 Jahre lang", "LTS-Zeitraum beträgt min. 18 Monate". Da kann man sich eine Version aussuchen, wo man der Meinung, da sind keine halbgaren Features drin.
Auch die Geschichte mit der versions.ini in der Cloud finde ich gut.

Ich weiß nicht, ob das mit hierrein gehört: Es wurde jetzt schon einige male besprochen und nie wurde eine definitive Aussage dazu getroffen: Wie sieht es mit der Aufrechterhaltung der Abwärtskompatibilität der API aus?
Zur Zeit werden sporadisch Teile der API gebrochen wodurch man trotzdem meist alle Erweiterung erneut testen muss. Nicht falsch verstehen, ich bin gegen eine dauerhafte Aufrechterhaltung der Abwärtskompatibilität, aber zur Zeit wird da ziemlich zweigleisig gefahren. Grade in Verbindung mit dem LTS, kann man unmittelbar nach dem Beginn einer neuen LTS-Periode auch mal größere Änderungen an der API vornehmen. Das erfordert natürlich auch etwas mehr Planung, da man solche API-verändernden Updates, dann gegebenenfalls um 18 Monate verschieben muss. Um das mal zusammenzufassen: "Weniger häufiger die API ändern, aber wenn dann klare Schnitte"

[Toflar]

Ich sehe es eher gerade umgekehrt. Es macht doch keinen Sinn LTS an Versionen zu knüpfen?
Ich nehme mal absichtlich Versionen, die es noch nicht gibt. Wo wir dann die bestehenden einordnen, kann man immer noch entscheiden.

Mal angenommen morgen, 27.08.2011, erscheint die Version 3.0.0 von Contao.
Die hat eine Konstante für das EOL - sagen wir mal das wäre der 27.08.2013.
Als Unternehmen weiss ich jetzt haargenau, dass wenn ich mich dazu entscheide die Version 3.0.0 einzusetzen, ich darauf zählen kann, dass meine Software noch 2 Jahre LTS kriegt und somit "bugfrei" ist.

Am besagten 27.08.2013 läuft der LTS ab (ob ich eine Meldung im BE erhalte oder nicht, ist ein Detail) und ich weiss, meine Version wird nicht mehr länger supportet. Ich muss mich also nach einer neuen Version umsehen. Die aktuelle Version auf dem Markt ist die 4.2.0.
Ich kann mich also jetzt entscheiden. Entweder ich setz direkt auf die neue Version, krieg viele neue Features und bin mir auch bewusst, dass ich wahrscheinlich meiner Webagentur ein bisschen mehr zahlen muss, weil die dafür sorgen müssen, dass die bestehende Seite geupdatet wird und das doch ein erheblicher Schritt ist.
Natürlich ist es an mir, sicherzustellen, dass alle Extensions zum Core für die 4.2.0 freigegeben sind. Vielleicht sind sie das aber nicht und ich entscheide mich dazu, die 4.0.0 zu nehmen, weil die Features zur 4.2.0 mich nicht sonderlich beeindrucken. Die Version 4.0.0 ist 2012 erschienen, da hab ich also noch ein Jahr LTS.
Zudem bleibt immer noch die Möglichkeit, dass ich jemanden dafür bezahle, dass er/sie den LTS der Version 3.0.0 weiterführt, aber das wäre dann inoffiziell und hat nix mehr mit dem offiziellen Contao-Team zu tun.

Wichtig an der Sache ist: Ich muss wissen, wie lange meine Version unterstützt wird und das ist halt, wenn man es an die Versionierung bindet, nicht wirklich gegeben. Also wenn ich meinen Kunden sagen würde "naja, halt bis zur nächsten Major-Version" sagen die mir "und das ist wann?"
Mit einer EOL-Konstante pro Version kann man es auf den Tag genau sagen und so auch Update-Fenster planen oder so. Ich denke das ist sehr, sehr wichtig.

Konsequenzen: Wir müssten alle Major- und Minor-Versionen der letzten zwei Jahre mit LTS ausstatten (deshalb meine Bemerkung, dass 2 Jahre evtl. ein bisschen lange sind). Allerdings würde ich jetzt hier wiederum nicht unbedingt Leo die Arbeit überlassen - vielleicht müsste man darüber diskutieren ob sich Leo auf das Implementieren neuer Features und Bugfixing in der aktuellen Version fokussiert und ein LTS-Team die Bugfixes backportet oder ob Leo das immer noch alleine machen will.

So, ich weiss, es ist jetzt schon ein Roman aber noch etwas zur API-Rückwärtskompatibilität. Ich denke, man könnte sich darauf einigen, die Rückwärtskompatibilität der API (und nur die der API, die Runonce für die DB brauchen wir immer noch!!) auf die Major-Versionen zu beschränken. Sprich die API der 3.4.* ist rückwärtskompatibel zur 3.0.0, aber die API der 4.* nicht zur 3.* und man kann deshalb auch davon ausgehen, dass alle Erweiterungen bei einem Major-Update nicht mehr funktionieren werden.

Ich kann mir auch vorstellen, dass die Benutzer das so kapieren würden. Wobei, vielleicht ist das mal wieder mein Optimismus
Just my two cents

[leo]

@toflar: Das wäre dann der genau andere Ansatz, also nicht die letzte stabile Minor-Version ist das LTS-Release, sondern die erste stabile Major-Version. Es gäbe dann eine 3.0.0 bis 3.0.999 (so viele Bugfix-Releases bis zur nächsten Major-Version eben) und parallel dazu eine 3.1.x, 3.2.x, 3.8.x etc. Dieser Ansatz hätte von der Planbarkeit her einen deutlichen Mehrwert, weil man als Unternehmen im einfachsten Fall genau wüsste, dass man nur alle 2 Jahr ein Upgrade machen muss. Allerdings frage ich mich dabei immer, wozu man dann weitere Minor-Releases braucht - wenn doch sowieso nachher nur das LTS-Release genutzt wird. Aus Entwicklersicht macht deswegen der letzte stabile Minor-Release für mich mehr Sinn.

[Toflar]

Jep, Minor-Releases machen in der Tat dann wenig Sinn. Man müsste sich halt dann entscheiden ob man weiterhin 2.10, 2.11, 2.12 machen will und sich die 3 für einen allfälligen Rewrite aufbewahrt oder ob man à la Mozilla und Google einfach nur noch Versionen 3, 4, 5, etc. machen will.
Scheinbar mögen das ein paar hier nicht, aber mal ehrlich...wen interessiert das schon, ob die jetzt "Version 4" oder "Version Pinguin" heisst? Wichtig ist doch, dass den Leuten klar gemacht wird, was das bedeutet.

Aus Entwicklersicht magst Du wohl Recht haben Allerdings frage ich mich dann wie das Verhältnis zwischen Entwicklern und Anwendern aussieht

Aber ist ja auch richtig so, wir wollen ja verschiedene Ansätze diskutieren. Mal gucken was die anderen dazu meinen

Etwas möchte ich meinem Vorschlag noch hinzufügen: Der Zeitraum des LTS ist fix definiert! Also wenn wir sagen, der LTS beträgt 2 Jahre, dann gilt das für jede Version. Es kann also nicht passieren, dass eine jüngere Version früher EOL hat als eine ältere (à la Windows Vista resp. XP - sowas wollen wir nicht, denke ich)

[tril]

Mal angenommen morgen, 27.08.2011, erscheint die Version 3.0.0 von Contao.
Die hat eine Konstante für das EOL - sagen wir mal das wäre der 27.08.2013.
Als Unternehmen weiss ich jetzt haargenau, dass wenn ich mich dazu entscheide die Version 3.0.0 einzusetzen, ich darauf zählen kann, dass meine Software noch 2 Jahre LTS kriegt und somit "bugfrei" ist.

Du willst jeden Release eine LTS geben? Wenn du ein vollständiges Team, dass sich dann um die 10 bis 20 betroffenen Contao Versionen kümmert bezahlst, wird das kein Problem. Ansonsten sehe ich darin ein Problem.
Ich gehe in deiner Aussage davon aus, dass du wirklich jedem Revision Release eine LTS zuweist, so klingt das zumindest für mich. Und selbst wenn du die LTS an den Minor Release bindest, kommst du in 2 Jahren immer noch auf 3 bis 4 Versionen, die du langfristig warten musst. Bei dem daraus entstehenden Aufwand wird Leo wohl kaum noch Zeit für Feature Entwicklung haben.

Wichtig an der Sache ist: Ich muss wissen, wie lange meine Version unterstützt wird und das ist halt, wenn man es an die Versionierung bindet, nicht wirklich gegeben.

Meine Rede, deshalb habe ich ja auch vorgeschlagen, die Versionierung vollständig zu ignorieren. Du willst in deinem Konzept EOL pro Minor/Release Version aber wieder die LTS an die Version binden. Selbst die großen Projekte, die potentiell viel mehr Entwickler zur Verfügung stehen, supporten maximal 2 Versionen, die LTS Version und die normale Version.

Auch mit meinem Vorschlag des 2 Jahres Zyklus für die LTS kann ein Unternehmen durchaus planen. Im Laufe der Zeit müssen sich die Agenturen und Unternehmen, die auf LTS setzen wollen halt mit dem LTS Release Zyklus einspielen. Und bevor du es jetzt für unflexibel hältst, ich sehe es als Kompromiss zwischen Aufwand und Nutzen. Der Aufwand jeden Major Release mit einem LTS auszustatten ist im Verhältnis zum Nutzen unrechtmäßig hoch.

So, ich weiss, es ist jetzt schon ein Roman aber noch etwas zur API-Rückwärtskompatibilität. Ich denke, man könnte sich darauf einigen, die Rückwärtskompatibilität der API (und nur die der API, die Runonce für die DB brauchen wir immer noch!!) auf die Major-Versionen zu beschränken. Sprich die API der 3.4.* ist rückwärtskompatibel zur 3.0.0, aber die API der 4.* nicht zur 3.* und man kann deshalb auch davon ausgehen, dass alle Erweiterungen bei einem Major-Update nicht mehr funktionieren werden.

+1

[Toflar]

@Tristan: Jap, richtig. Ich hab effektiv davon gesprochen, jeweils immer alle Versionen (stable latürnich) der letzten n-Jahre mit LTS auszustatten. Deshalb hab ich ja geschrieben, dass ich 2 Jahre für ein bisschen lange halte

Und ja, es ist ein grosser Aufwand und wie das Marc bereits erwähnt hat, wäre das ein neuer - für viele Firmen da draussen - sehr toller Pluspunkt für Contao

Nehmen wir mal an, Leo würde wie bis anhin immer noch 2x pro Jahr eine neue Version veröffentlichen. Dann müssten wir immer 4 Versionen mit LTS ausstatten. So meinte ich das, aber ich seh schon, dass der Aufwand sehr gross ist

[leo]

Nein, LTS kann es immer nur für eine oder maximal zwei Versionen geben. Und das sind entweder die jeweils letzten Minor-Versionen jedes Branches oder eben das erste stabile Major-Release. Welche Variante besser ist, bleibt zu diskutieren.

[tril]

@Tristan: Jap, richtig. Ich hab effektiv davon gesprochen, jeweils immer alle Versionen (stable latürnich) der letzten n-Jahre mit LTS auszustatten. ...
...Nehmen wir mal an, Leo würde wie bis anhin immer noch 2x pro Jahr eine neue Version veröffentlichen. Dann müssten wir immer 4 Versionen mit LTS ausstatten. So meinte ich das, aber ich seh schon, dass der Aufwand sehr gross ist

Also redest du von Major/Minor Releases? Wenn hier immer nur mit dem Begriff "Version" oder noch besser "alle Versionen" um sich geschmissen wird, ist es total schwierig einzuschätzen wovon du redest. Vor allem weil xtra weiter oben mal davon Sprach die Release Version als LTS zu setzen, andere reden von der Minor Version.

Eine bitte an alle: nicht schwammig, sondern klar die Versionen um die es geht benennen, sonst versteh (ich zumindest) es vorne und hinten nicht mehr

...Deshalb hab ich ja geschrieben, dass ich 2 Jahre für ein bisschen lange halte
Und ja, es ist ein grosser Aufwand und wie das Marc bereits erwähnt hat, wäre das ein neuer - für viele Firmen da draussen - sehr toller Pluspunkt für Contao

Jeder LTS < 2 Jahre ist für die meisten Unternehmen absolut uninteressant, von daher kann ich deiner Idee immer noch nichts abgewinnen. Der Nutzen erschließt sich mir einfach nicht.
Entweder wir reden von LTS oder andauernder Pflege und Aktualisierung. Ich habe mich schon mit "Unternehmern" die auf Jahre kalkulieren auseinander setzen dürfen. Für solche Leute, die überhaupt über LTS nachdenken sind meiner Erfahrung nach 2 Jahre fast schon zu wenig, aber der richtige Mittelpunkt zwischen Stillstand und Aktzeptanz durch die Unternehmen.

[tril]

Nein, LTS kann es immer nur für eine oder maximal zwei Versionen geben. Und das sind entweder die jeweils letzten Minor-Versionen jedes Branches oder eben das erste stabile Major-Release. Welche Variante besser ist, bleibt zu diskutieren.

Und was hältst du davon, es an dem LTS Zeitraum, statt an Major oder Minor Releases fest zu machen? Das wäre für Unternehmen planbar und du wärst nicht gezwungen im Zeitraum X eine neue Version zu releasen.

[leo]

@tril: Ja, die Idee finde ich nicht verkehrt. Sie lässt uns eventuell etwas mehr Flexibilität.

[tril]

Vor allem, kochen wir dann nicht unseren eigenen Brei. Ich finde zwar Einheitsbrei bei Webseiten zum k****, aber Entwicklungsprinzipien, die nicht nur bei Entwicklern, sondern auch Unternehmen bekannt sind ist immer Vorteilhaft (zumindest Ansatzweise) anzunehmen. Damit fällt man nicht so sehr aus dem Rahmen so nach dem Motto "was haben die den für merkwürdige LTS Zyklen"
Individualismus ist gut, so lange man nicht negativ aus dem Raster fällt, ich glaube, das würde uns passieren, wenn wir irgendwelche Willkürlichen Zyklen anstreben.

[BugBuster]

Also man sucht sich nun als erstes mal die erste LTS, sagen wir mal das wäre die 2.9.5, und nach 1,5 Jahren (halbes Jahr vor Ablauf) beginnen wir dann die nächste festzulegen, z.B. 3.4.7, die dann mit Ablauf der 2.9.5 zur neuen LTS wird.
So in der Art?
In dem halben Jahr können dann die Agenturen schon anfangen die Upgrades zu testen und anzubieten :-)

[tril]

Also man sucht sich nun als erstes mal die erste LTS, sagen wir mal das wäre die 2.9.5, und nach 1,5 Jahren (halbes Jahr vor Ablauf) beginnen wir dann die nächste festzulegen, z.B. 3.4.7, die dann mit Ablauf der 2.9.5 zur neuen LTS wird.
So in der Art?
In dem halben Jahr können dann die Agenturen schon anfangen die Upgrades zu testen und anzubieten :-)

Ja das wäre so das ungefähre Prinzip.

[BugBuster]

Nebenbei, ich kenne auch Privatpersonen die sich über eine LTS freuen würden, ich gehöre auch dazu, die wollen nicht ständig die neusten Features, aber die Security Bugfixe sollen es schon sein.
In meiner Download Übersicht der älteren Systemchecktools ist deutlich zu sehen, das immer noch 2.5.x, 2.6.x im Einsatz sind.
Denen eine Sicherheit zu bieten eine Weile, wäre schon ein Pluspunkt für Contao.
Wobei die 2.6.7 vom 11.03.2009 schon raus wäre aus den 2 Jahren, nunja, man kann nicht alles haben.

[backbone]

Apropos Statistik:
Kann man nicht zusammen mit dem Update-Check der jetzt schon im System, die derzeitig eingesetzte Version mitschicken?
Da hätte man ein bisschen den Überblick wie weit, welche Versionen verbreitet sind. Für Paranoide sollte dieses Verhalten natürlich abschaltbar sein.

[andreas.schempp]

Bin ich der Einzige der findet dass wir wichtigere Baustellen als LTS haben?

[Toflar]

Nö, aber die Release-Planung ist wichtig, damit wir die Baustellen auch planen können. Oder hast Du schon mal eine Roadmap gesehen?

[andreas.schempp]

Das nennt sich Roadmap: http://dev.contao.org/projects/typolight/roadmap

[Dani]

Ich wäre dafür, dass ca. alle 2 Jahre ein Major-Release herauskommt. Bei diesen Major-Release'n sollen aber keine Rückwärtskompatiblität garantiert werden, nur bei Minor-Release'n. Ich finde der "unnötige Code" sollte mal gründlich entfernt werden (aber auch die Ordner, wie z.B. typolight). Nur weil der Name von "TYPOlight" zu "Contao" geändert wurde, heisst das noch lange nicht, dass das CMS Contao nicht mehr "light" gehalten werden soll.

[andreasisaak]

Bin ich der Einzige der findet dass wir wichtigere Baustellen als LTS haben?

Nein, du bist nicht alleine. Ich halte das Verfahren auch für unnötig! Ich habe schon bei TYPO3 keine Vorteile bei diesem Aktualisierungsprozess gesehen und tue es bei Contao noch weniger.

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