= Releases = [[TOC(heading=Inhoudsopgave)]] [[TOC(heading=Hoofdstukken, sectionindex, compact, depth=2, Documentatie/Ontwikkelhandleiding/*)]] [[NoteBox(note, OpenAC werkt niet meer met een time-based release, maar met een feature-based release. Zie de [wiki:Releases releases] pagina voor informatie over welke features geselecteerd zijn voor welke release. De procedure met twee pilot-AC's blijft behouden.)]] * De releasedatum is de datum dat de acceptatieversie wordt aangemaakt door de development-branch te kopiëren naar een release-branch. De releasedata vallen in principe op 31-3, 30-6, 25-9 en 15-12 (4x per jaar). * 5e week voor releasedatum: scope bepalen, ontwerpjes maken * 4e en 3e week voor releasedatum: bespreken ontwerpjes voor de grotere tickets, tickets afwerken * 2e week voor releasedatum: testen (en soms nog wat losse eindjes ontwikkelwerk), 2 pilot-AC's zoeken * week voor releasedatum: documenteren, changes overnemen en live (zie hieronder) * week na releasedatum: test bij 2 pilot-AC's, changes overnemen, bericht productieversie live == Testen en maken van een OpenAC release == Je zit in een werkkopie van de tak 'development'. Doe nu de volgende stappen: - '''Splash''' - de splash-screen controleren en bijwerken. Uit ticket #2454: - Open `images/splash.xcf` met GIMP, - Werk copyrightboodschap bij, dus ''(C) 2004 - 2010''. Klik op de layer ''achtergrond'' om die onzichtbaar te maken. Klik dan op het tekst-tool icoon (vette '''A''' in de toolbox). Dubbel-klik op het tekstveld dat nog een beetje zichtbaar is, dialoog verschijnt. Pas de tekst aan. - Sla op, - Sla op als `splash.png`, File -> Save As -> Vul filenaam in. Je moet nog kiezen om de PNG plat te slaan (''merge visible layers''). - Controleer met een andere plaatjes-viewer dat de splash nu klopt. - Commit de gewijzigde twee bestanden. - '''Merge''' - wijzigingen coordineren zodat development acht de laatste wijzigingen bevat. * Ga op de TRAC-website onder "Timeline" naar de vorige release, en loop zorgvuldig de changesets na die sindsdien zijn ingevoerd, draai eventueel een DIFF. Dit gebeurt elke week maar moet vlak voor een release nog een keer worden herhaald, zodat op het moment dat de release note uitkomt, alle wijzigingen zijn overgenomen. Wat men daarna inlevert, moet men zelf weten (versiebeheer waarschuwt dan ook). Zie ook [wiki:Ontwikkelhandleiding/Source#Wijzigingenovernemen kopje wijzigingen overnemen] voor technische details. * Controleer of alle wijzigingen in de loop van de vorige release zijn overgenomen: development/bin/adaptatie-diff v1.XXX development (vergelijk laatste versie met development). Loop de diff door op vergeten change sets. Als er regelmatig met svn merge is gewerkt is dit wellicht overbodig. - '''Test''' - technische en functionele tests van huidige development versie. Hiervoor moet je wel een werkende OpenAC configuratie-directory (bv. `.openac`) hebben. {{{ python unittests.py --enable-all --no-adaptaties python unittests.py --with-adaptaties }}} * Draai de '''unit tests''' en fix zonodig, {{{python unittests.py --enable-all}}} . De unit tests vormen een automatische test die al ruime tijd voor alle releases wordt gedraaid. Deze test simuleert voor elk van de adaptaties een login en "drukt" vervolgens achtereenvolgens alle knoppen van het startscherm in. De unit test maakt gebruik van lege, standalone sqlite3-databases. * Draai de '''systeemtest'''. De systeemtest vormt een automatische back-to-back test voor de academische huizen. Deze voeren we bij elke release uit. In overleg met academische huizen wordt het testrapport overlegd, maar meestal blijft dit intern. '''TODO:''' ''hoe'' draai je de systeemtest? * Loop het [TestProtocol test protocol] door. Dit is een (gebruikers-)functionele test van OpenAC. - '''Opschonen''' - de source code helemaal netjes maken voor release. {{{ sh bin/clean python unittests.py --enable-all svn commit }}} * Werk '''VERSIES.txt''' bij door de releasedatum aan de laatste versie toe te voegen en de omschrijving af te maken. Daardoor verschijnt het in de beschikbare versies lijst van de ACs. * Draai {{{bin/clean}}} en commit eventuele bestanden die nog geen eol-style LF hadden. * Draai nog 1x de unit tests, {{{python unittests.py --enable-all}}} * Doe nog eens reindent om de code style recht te trekken, {{{python bin/reindent.py `find . -name *.py`}}} - '''Branch''' - in SVN de branch maken * Draai {{{bin/release 1.XXX}}} om development te kopiëren naar de nieuwe release in SVN. * Maak de adaptatiemap in de nieuwe release schrijfbaar voor centra door 3 regels te kopiëren in de TRAC configuratie. Zie daarvoor de TRAC configuratie wiki elders. - '''Test nogmaals''' - of het na de branch nog doet. * Check de nieuwe versie uit en controleer nogmaals dat het -- nu als eigen release -- nog steeds start. Loop nogmaals cluchtig het test protocol door. * Start een eerdere versie op, ga naar versiebeheer en controleer dat (1) de nieuwe release in de versies lijst staat en (2) opschakelen naar de nieuwe release kan. - '''Announce''' - maak de nieuwe versie bekend * Maak een nieuwe starterkit. * Stuur een release-bericht naar openac@fenac.nl. Denk daarbij goed na welke migraties er allemaal gebeuren bij deze nieuwe versie. === Maken van een nieuwe starter kit === De starterkit wordt gemaakt met NSIS ([http://nsis.sourceforge.net/Main_Page NullSoft Scriptable Installation System]). Die kan een paar configuratie-vragen stellen en OpenAC met een specifieke configuratie op een bepaalde plek installeren. Op de OpenAC server is `makensis` geinstalleerd. Soms zijn er Linux packages voor; op SourceForge is in ieder geval een `setup.exe` beschikbaar voor Windows. Om een starterkit te maken heb je een checkout van development nodig (of in ieder geval `development/bin`), makensis en een shell. De starterkit wordt gemaakt door het script `bin/starterkit.py`. Gebruik `--help` voor configuratie-opties bij het maken van de starterkit. Over het algemeen is dit voldoende: {{{ bin/starterkit.py -v }}} Waarbij VERSIE een '''inmiddels aangemaakte''' `release/` branch is. De "v" is optioneel, dus `-v 2.002` is hetzelfde als `-v v2.002`. Er wordt dan een checkout gemaakt van die versie, samen met de Python runtime, dan wordt van de template NSIS-file een specifiek installer-script gemaakt en met makensis tot een `starterkit.exe` gemaakt. Op de OpenAC server duurt dit ongeveer 20 minuten in totaal. De resulterende executable mag naar de downloads folder worden gekopieerd. Er worden MD5 en SHA1 checksums geprint voor gebruik in de release notes of op de starterkitpagina.