Joomla! versies en updates uitgelegd

Op 1 april 2012 schreef Mark Dexter in Joomla Magazine een artikel over de Joomla! updates en versies. Op 3 april 2012 is dit vertaald door Wouter Franken voor JoomlaNL.

Achtergrond-informatie december 2009, New York City Toen het nieuw gevormde Production Leadership Team (PLT) elkaar ontmoette in New York City in December 2009, hadden we een uitdaging. Ondanks dat Joomla! versie 1.5 populair en succesvol bleek, was het wel een versie die al twee jaar daarvoor was uitgekomen. De code voor versie 1.6 bevatte nog vele incomplete en niet geteste mogelijkheden en niemand kon aangeven wanneer versie 1.6 klaar zou zijn voor officiële vrijgave. (Het heeft uiteindelijk nog meer dan een jaar geduurd, totdat in januari 2010 versie 1.6 uitkwam).
Het is eigelijk overbodig om te zeggen dat deze trage release-methode en onduidelijke toekomst geen goede situatie waren voor zowel het project als ook voor de hele gebruikers-community. Dus besloten we om een koers uit te zetten waaop we de hudige situatie konden verbeteren en dit soort situaties in de toekomst zouden kunnen voorkomen. We namen twee belangrijke beslissingen tijdens die bijeenkomst: ga vanaf nu uit van een stabiele basis in de code en start met het uitbrengen van nieuwe versies via een vast tijdsschema.

Stable Trunk / stabiele code

In software-versiebeheertermen spreekt men van de trunk (denk aan een boom). Het is de code die wordt gebruikt om een werkende versie van een programma op te kunnen leveren. Ontwikkelaars kunnen branches aanmaken (Kopieën van de trunk's code) om mee te werken aan grote aanpassingen, zoals het toevoegen van nieuwe toepassingen. Door te werken in een branche, kan een groep ontwikkelaars alle aanpassingen maken die ze willen, zonder dat het effect heeft op het hoofdprogramma of op dat van andere ontwikkelaars die ook in andere  branches bezig zijn.. Als een nieuwe toepassing is getest en gereed, dan wordt de branche voor die mogelijkheid samengevoegd in de trunk en wordt zo onderdeel van de volgende versie.
Het idee achter een stabiele trunk is eenvoudig: Een branch (denk aan een nieuwe toepassing) wordt niet in een trunk samengevoegd voordat het compleet is en volledig getest en klaar voor vrijgave. Dit lijkt eenvoudig maar in de praktijk kan het wel eens lastig zijn. Een voorbeeld: Een nieuwe toepassing lijkt voor 99% klaar te zijn, op een paar kleine dingen na die ook later nog wel aangepast kunnen worden. Het kan dan heel verleidelijk zijn om dit dan toch maar toe te voegen. Vooral als het een hele belangrijke toevoeging is en de opleverdatum voor de nieuwe release in zicht komt. Het niet leuk om het nieuws te moeten ontvangen dat een nieuwe toepassing waar je lang aan hebt gewerkt niet wordt opgenomen omdat het is is geaccepteerd.
Wat zijn de voordelen van deze manier van werken met een stabiele trunk?
Een voordeel is dat verschillende teams van ontwikkelaars onafhankelijk van elkaar in verschillende branches kunnen werken met de garantie dat er niets halfbakken in de trunk komt, wat mogelijk weer met andere code kan botsen. Hierdoor wordt de kans dat wat het ene team bouwt invloed heeft op het andere team sterk verkleind. Een ander voordeel van een stabiele trunk is dat je op elk moment een stabiele versie kunt uitbrengen. Dit maakt het uitbrenegn van releases via een vast schema mogelijk.

Releases uitbrengen via een vast schema

Zoals de Deense natuurkundige Niels Bohr ooit zei; "Voorspellen is erg moeilijk, zeker in de toekomst."Dit gaat ook zeker op voor de voorspelling wanneer een nieuwe software-versie gereed is. Dat wordt helemaal duidelijk in een vrijwilligers-omgeving zoals het Joomla Project. In een bedrijf is het, over het algemeen, bekend hoeveel mensen er aan een taak kunnen werken. Met Joomla! weten we niet wie er aan iets werkt en hoeveel uren of dagen zij beschikbaar hebben. En al helemaal niet wanneer ze iets gereed hebben. Het is dus vrijwel onmogelijk om voorspellingen te doen wanneer bepaalde nieuwe toepassingen beschikbaar komen.
Van de andere kant, zijn er vele voordelen voor de community om een voorspelbaar updateschema te hebben. De oplossing van het PLT was om een gepland schema op te stellen, maar wel met strikte voorwaarden. Er mag geen garantie worden gevraagd op het moment van uitkomen van een specifieke toepassing.  Bijvoorbeeld: We kunnen met enige zekerheid voorspellen dat we versie 3.0 van Joomla! In september 2012 uitbrengen. Maar we weten niet welke toepassingen er dan in zullen zitten, todat ze zijn afgerond en toegevoegd aan de basis-code.

STS en LTS releases

Met de hierboven beschreven achtergrond in gedachten, gaan we eens kijken naar specificaties van de huidige Joomla-release-cyclus. In diezelfde bijeenkomst in 2009, heeft het PLT zichzelf een ambitieus doel gesteld – om elke zes weken een nieuwe Joomla!versie uit te brengen.Waarom zo frequent een nieuwe versie uitbrengen?
Een belangrijke reden is dat de ontwikkelaars zo gemotiveerd worden. Vrijwilligers die code opleveren aan het project willen graag zien dat de code van hun toepassing wordt gebruikt. Als de tijd tussen twee nieuwe versies te lang wordt, dan zakt de motiverende factor.
Vaker een nieuwe versie uitbrengen maakt het ook eenvoudiger om in te spelen op de wijzigingen in de software waar Joomla! Op draait. Zoals PHP, MySQL en TinyMCE. Ook deze programma’s zijn constant in ontwikkeling en we moeten hier met de ontwikkleingen van Joomla! Op in kunnen spelen.

Om dit ambitieuze doel te kunnen halen, moeten we er zeker van zijn dat de updates eenvoudig op te leveren zijn. Zo was de overgang van 1.5 naar 1.6 een uitdaging. Dit werd zo uitgebreid omdat er zo veel wijzigingen waren tussen deze twee versies. Aan de andere kant waren de updates van 1.6 naar 1.7 en 1.7 naar 2.5 (hopen we) relatief eenvoudig. En we werken er continue aan om ze nog beter en meer ‘bulletproof’ te maken. Zo hebben we sinds 2.5 de automatische update-berichtgeving. En we werken aan de introductie van een nieuw updatesysteem dat ook beter zal werken bij tragere hostingproviders.

Het regelmatig uitbrengen van nieuwe versies betekend ook dat we voorzichtig zijn met  ‘backward compatibility’. Bijvoorbeeld dat extensies die werken met versie 1.6 het ook nog moeten doen met 1.7 en 2.5.

Maar zelfs met betere updates en goede compatibiliteit, constateert het PLT dat een zes-maanden-releasecyclus niet goed is voor veel websites. Dat is dan ook de reden dat we het idee lanceerden voor Lange Termijn Support-releases (LTS). Voor 1.6 en 1.7 hanteerden we de Standaard Termijn Support (STS). Joomla! 2.5 is dus weer een LTS-release. Dat betekend dat 2.5 minimaal zal worden ondersteund totdat de eerste LTS-release (versie 3.5) beschikbaar is. Dit staat op dit moment gepland voor september 2013.

Het idee van LTS en STS is dus vrij eenvoudig. Als je de nieuwste toepassing gelijk wil meepakken, dan moet je meegaan met de STS releases – bijvoorbeeld 3.0 in september 2012, 3.1 in maart 2013 en 3.5 in september 2013.Als je stabiliteit wil en voldoende hebt aan de mogelijkheden van 2.5, blijf dan 2.5 gebruiken totdat 3.5 is uitgebracht. Update dan pas naar 3.5.
Zo ook hetzelfde met versie 4. Volg het 4.1 / 4.5 pad om de meest actuele ontwikkelingen bij te houden of wacht op 4.5 om zo het aantal tusentijdse updates te beperken.

Die keuze is uiteindelijk aan iedere gebruiker zelf. De enige voorwaarde is deze: Als je meegaat met de STS release (zoals 3.0 en 3.1), dan moet je beseffen dat die maar een korte levensduur hebben en dat je dus elke zes maanden moet updaten totdat de nieuwe LTS beschikbaar is. (bijvoorbeeld 3.5).  Op dat moment kun je beslissen om op het pad van de STS-releases te blijven (en dus gaan voor 4.0 / 4.1 / 4.5) of schakel over naar het LTS-pad  (en wacht op versie 4.5).
Ik hoop dat dit helpt om de hudige release-cyclus te kunnen begrijpen. Hieronder nog enkele FAQ 's.

FAQ's

Waarom gingen we ineens over van versie 1.7 naar 2.5?
In een bijeenkomst in juli 2011 heeft het PLT besloten om dingen eenvoudiger te maken. Zo werd besloten dat alle LTS-releases standaard als versiecode X.5 zouden krijgen. (1.5, 2.5, 3.5en zo verder). Om op dat plan te komen, zouden we:
a) volgende release in januari 2012 nog 1.8 kunnen noemen, zoals eerst was gepland in de X.5 nummering door kunnen gaan naar versie 2.
b) we zouden in één keer kunnen overgaan van versie 12.7 naar 2.5 en dan 2.5 kunnen opvoeren als de LTS-release.
We hebben besloten om hierover binnen de community te stemmen en de community koos voor plan b. Zo werd in januari 2012 de relase 2.5 uitgebracht in de hudige LTS-release.

Waarom is 3.0gepland voor september 2012 in plaats van juli 2012?
Terwijl we bezig waren met de 2.5 release werd al snel duidelijk dat december een lastige maand is voor veel mensen om aan zo’n project te werken.  Na veel discussies is besloten om de releases te verschuiven van juli en januari naar maart en september. We zullen het schema van elke zes maanden een nieuwe versie uitbrengen aanhouden, maar we zullen wel op een bepaald moment  de release-maanden bepalen. Op dit moment is 3.0 gepland voor september 2012, 3.1 voor maart 22013 en 3.5 voor september 2013.

Wanneer zal versie 1.5 end-of-life zijn (dus niet meer ondersteund worden)?
Het originele plan voor versie 1.5 was om het te laten eindigen on april 2012. Toch heeft een groot aantal mensen er op aangedrongen te bekijken of deze periode kan worden verlengd. Een praktisch punt is dat 1.5 niet veel updates heeft gehad in het afgelopen jaar. Dat betekende dat er niet veel tijd uit het project nodig was om deze versie te onderhouden. Er is vanuit het PLT nog geen formele aankondiging, maar de ondersteuning voor 1.5 zal na april 2012 nog worden voortgezet. Waarschijnlijk tot september 2012.
 
Zullen de wijzigingen van 2.5 naar 3.0 groter zijn dan de wijzigingen van 1.7 naar 2.5?
In theorie kan de wijziging van 2.5 naar 3.0 groter zijn dan die van 1.7 naar 2.5. Omdat van alle 1.7 gebruikers werd verwacht  dat ze zouden updaten naar 2.5, moest die update zo soepel mogelijk verlopen met de hoogste graad van backward compatibility als mogelijk.
Met de 2.5 naar 3.0 update is de situatie anders. Versie 2.5 gebruikers hebben de optie om op 2.5 te blijven draaien voor de dan nog lopende support-periode (en dan eventueel updaten naar versie 3.5) of updaten naar 3.0. Omdat de update naar 3.0 optioneel is er meer marge in de mogelijke wijzigingen tussen 2.5 en 3.0 waardoor een migratie van sommige extensies mogelijk zal zijn.

In ieder geval proberen we de update zo  eenvoudig mogelijk te maken met uiteraard de hoogste graad van backward compatibility als mogelijk is. De overgang van 3.0 naar 3.1 en 3.1 naar 3.5 zullen we ook zo sopel mogelijk laten verlopen. Maar onthou wel dat we nu nog niet kunnen voorspellen welke toepassingen dan beschikbaar zullen komen. Dus kunnen we nu nog niet bepalen hoe groot de wijzigingen zullen worden, totdat we in de buurt van de releasedatum komen.

Kan de release-cyclus in de toekomst nog veranderen?
De hudige release-cyclus is niet ‘in steen gebeiteld’ en kan dus in de toekomst worden gewijzigd op basis van ervaringen en terugkoppeling uit de community. Eenmaal aangekomen op versie 3.0 zijn we door een volledige cyclus van STS en LTS releases heen. Op dat moment wordt het belangrijk om te evalueren hoe het gaat en of er wijzigingen in deze opzet moeten worden aangebracht.


Reageren op dit artikel kan op het JoomlaNL-forum via deze link.