Levensduur versie
| MediaWiki |
|---|
|
| Oudere versies |
| Levensduur versie |
MediaWiki werkt met een "continuous integration" ontwikkelingsmodel, waar software-wijzigingen in productie op een reguliere basis worden ingevoerd op de Wikimedia websites zoals Wikipedia.
In theorie is er elk half jaar een grote release, release branches ontvangen gedurende een jaar veiligheidsupdates na hun eerste release. Door de beschikbare tijd en snelle ontwikkeling van de code kunnen oudere releases niet eeuwig blijven worden ondersteund. Elke versie heeft een beperkte levensduur.
De release manager beveelt aan dat wiki operators zich aanmelden voor de mediawiki-announce mailinglijst, dan krijgen zij bij elke release een aankondiging, en kunnen zij de upgrade van hun wiki's zelf inplannen. Deze meldingen komen ook op mediawiki-l en wikitech-l.
Versies en hun levensduur
| Versie | Status | Release | Einddatum |
|---|---|---|---|
| 1.44.x | toekomstige versie | ||
| 1.43.x (LTS) | toekomstige lange termijn ondersteuning versie | ||
| 1.42.x | huidige stabiele versie | ||
| 1.41.x | oudere versie | ||
| 1.40.x | verouderde versie | ||
| 1.39.x (LTS) | huidige lange termijn ondersteuning | ||
| 1.38.x | verouderde versie |
De hierboven genoemde versies die als verouderd zijn aangegeven en versies die helemaal niet genoemd worden ontvangen geen veiligheidsupdates. Dit omvat ook alle versies die ouder zijn dan de oudste vermelde versie. Zij kunnen dus onveilig zijn en ook andere fouten bevatten. De release manager beveelt sterk aan' dat alleen de hierboven genoemde “stabiele versie”, "oudere versie" en “lange termijn ondersteuning versie” worden gebruikt in een productie-omgeving.
- Alpha ontwikkeling
- Release ontwikkeling
- Stabiele release
- Lange termijn ondersteuning release
Release beleid
- Elke 'point release' zal de bijgewerkte i18n bestanden bevatten en natuurlijk alle opgeloste fouten. Er worden geen nieuwe functies toegevoegd aan oudere 'point releases' en de ondersteuning geldt niet noodzakelijk voor de gebundelde extensies en skins.
- Er is elke zes maanden een major release.
- Elk kwartaal is er een minor release (inclusief veiligheidsupdates, vertaalde berichten back-ports en opgeloste fouten).
- Elke twee jaar wordt er een lange termijn ondersteuning release (LTS) gemaakt. Er is een jaar overlap in ondersteuning bij LTS ondersteuning. Een voorbeeld, versie 1.23 is ondersteund tot mei 2017. Versie 1.27 is een jaar eerder uitgebracht. Mensen die de LTS gebruiken hebben dan een jaar de tijd om over te stappen.
- 'Release notes' zijn de basis om de wijzigingen in de versies aan te geven. Omdat wij een project zijn met vrijwilligers, is het lastig om aan te geven wat er een komende periode zal gebeuren.
Tijdlijn
Dit tijdschema geeft alleen de planning van de releases aan. De echte datum van de release wordt met een T (van "tijdstip" van release) aangegeven met een suffix -# (voor het aantal weken voor de release).
| Relatieve schema | Taak |
|---|---|
| T - 7 | Aankondigen dat er over een week een release branch wordt uitgebracht. Zorg ervoor dat lopende ontwikkelingen zo mogelijk dan kunnen worden ingepast in die release. In Phabricator aanmaken van een "MW-X.XX-release". |
| T - 6 | Aanmaken van de branch voor de core en alle extensies in Gerrit. |
| T - 5 | Pas de tag X.XX-rc.0 toe en geeft de initiële release kandidaat vrij. |
| T - 4 | Verzamel de foutrapporten en maak een samenvatting in de mailinglijst. |
| T - 3 | Pas de tag X.XX-rc.1 toe en geef de tweede release kandidaat vrij. Als er nieuwe extensies voorgesteld zijn om deel uit te gaan maken van de tarball, dan zouden die er nu in moeten zitten. Hierna in de release geen wijzigingen meer van de extensies. |
| T - 2 | De nieuwe foutrapporten verzamelen, fouten oplossen, herstellen nieuwe fouten, kijken naar onvolledige functies die per ongeluk zijn meegenomen, toepassen van tag X.XX-rc.2 tag en het vrijgeven van de derde release kandidaat. |
| T - 1 | Herhaal de vorige stappen, gebruik voor de tag X.XX-rc.final en geef de versie vrij. Er worden vanaf nu geen wijzigingen meer gedaan die ook op eerdere ondersteunde versies worden gedaan (geen 'backports' meer). |
| T | TAG de repository met X.XX en doe de release. |
Extensie levensduur
De meeste MediaWiki installaties bevatten veel extensies (Wikimedia wiki's zo rond de 140). Het beheren van opgeloste problemen en het kiezen van de goede versie is bij het beheren van een installatie een uitdaging. U moet bij een wijziging van de versie van elke extensie bedenken of die wel past op uw versie van Mediawiki.
De beheerders van een extensie raden u daarom aan om git branches voor elke extensie versie te onderhouden per geschikte versie van de MediaWiki.
(Meer informatie.)
Voor de extensies die gehost zijn in de Wikimedia's git repos, zoals branches (met namen als REL1_30 voor MediaWiki 1.30) worden automatisch aangemaakt uit de 'master' als er een branche wordt gemaakt voor een nieuwe MediaWiki versie (met de aanname dat de extensie altijd op master-niveau compatibel is met MediaWiki).
Het is echter fijn als de onderhouder van de extensie fouten niet alleen oplost in de HEAD maar ook in de oudere en stabiele versies van de extensie (door 'backporting' van oplossingen naar oudere nog ondersteunde versies).
Het doel van deze regels is dat mensen en organisaties bij het installeren van MediaWiki er op kunnen vertrouwen dat bij het installeren van de nieuwe release van een versie en overeenkomende extensies met een eenvoudige methode kunnen kiezen, bijvoorbeeld voor 1.20.x core aan REL1_20 refereren in git.
Het voorkomt dat tarballs en zip-bestanden niet relevante of zelfs wisselende en dus onvoorspelbare namen hebben.
Zie ook
- Compatibiliteit informatie over MediaWiki, de belangrijkste zijn PHP en MySQL
- Stabiel interface beleid
- Generatoren op WikiApiary - Statistieken over het gebruik van verschillende versie van de MediaWiki.