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 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 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@…. 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 (​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 <VERSIE>

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.