Release-Zyklus und Long Term Support

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?).

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.

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)

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

Ich auch! :)

Zitat:

---

Zitat von andreas.schempp

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

---

+1 :)

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

Zitat:

---

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.

;)

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!

Zitat:

---

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

Zitat:

---

Zitat von folkfreund

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? :D

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.

Zitat:

---

Zitat von 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.

---

Äh, richtig, ja :) So kann man das auch sehen, natürlich :)

Zitat:

---

Zitat von tril

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.

---

Jein. Du hast zwar Recht, aber wenn sich Leo daran hält und jedes Jahr eine neue Major bringt, dann hast Du LTS für ein Jahr, es sei denn Du bist gerade auf der aktuellsten eingestiegen, dann hast Du sogar 2 Jahre (ein Jahr hast Du die aktuellste, dann ein Jahr LTS).

Allerdings stimme ich dir zu, von Long-Term kann hier nicht mehr die Rede sein. Allerdings hat die Diskussion ja auch ergeben, dass Contao sowas theoretisch noch nicht braucht.

Allerdings wäre der Support für die vorangehende Major ein tolles Verkaufsargument. Ob man das jetzt LTS nennt oder nicht, ist eher eine Marketingfrage...denk ich mal :)

So, die Ergebnisse wurden in einen angepassten Releasezyklus eingearbeitet.

http://www.contao.org/blog-leser/ite...asezyklus.html

Vielen Dank an alle, die sich Zeit genommen und bei der Neugestaltung geholfen haben.