* Etwa einen Monat vor dem Release wird eine Beta herausgegeben.
-* (TODO: Reease Candidates Zeitplan).
+* (TODO: Release Candidates Zeitplan).
1. KONSISTENZ DES PROGRAMMS
===========================
+* Testlauf t/test.sh
+
+ - Im Moment sind 4 Fehler optimal (die sind noch nicht angegangen):
+ o bin/mozilla/ar.pl contains at least 190 html tags.
+ o bin/mozilla/ic.pl contains at least 130 html tags.
+ o bin/mozilla/ap.pl contains at least 183 html tags.
+ o bin/mozilla/admin.pl DOES NOT use proper system or exec calls
+ - Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus.
+ TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde.
+ TODO: Dokumeniteren wie der Releasemanager sich so eine DB baut, die
+ sollten vor einem Release zumindest durchlaufen.
+ TODO: Evtl eine Klasse von Releasetests einführen)
+
+* Testinstallation aus dem git mit neuer auth Datenbank.
+
+ - Änderungen die die auth Systeme betreffen zerreissen gerne mal die initiale
+ Installation.
+
+* Testupgrade auf einer Vorversion.
+
+ - Dito nur mit Upgradescripten. Fehlerhafte Abhängigkeiten können dazu
+ führen, dass Upgradescripte nicht in der richtigen Reihenfolge ausgeführt
+ werden, was bei inkrementellem Testen nicht auffällt.
+
* Freeze auf der Mailingliste ansagen.
- Featurefreeze für beta
* Changelog aktualisieren.
- Im Changelog sollten sämtliche behobenen Bugs seit der letzten Version
- aufgeführt sein. (TODO ist mit ein bisschen SQL Magie direkt aus der
- Bugzilla Datenbank holbar, diese Magie hier möglichst dokumentieren).
+ aufgeführt sein.
+
+ Beispiel für semiautomatisches bearbeiten:
+
+ o Letztes Releasedatum: git log --pretty=format:%cd <release-tag> | head -1
+ o Alle Bugs seit dem mit der Buzilla advanced search suchen:
+ + Bugs changed
+ + Only bugs changed between <letztes Releasedatum> and Now
+ + where only one or more of the following changed: "Resolution"
+ + and the new value was: "FIXED"
+ o columns ändern auf nur "Full Summary"
+ o copy&paste in eine Datei
+ o perl -pale '$_=" - Bugfix $F[0]: @F[1..$#F]"' oder awk/sed drüber
+
- Ausserdem einmal durch das git scrollen und sinnvolle grössere Änderungen
ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach
nur noch inkrementell.
$ scripts/find-use.pl
- Die Ausgabe zeigt alle "use *", "use parent qw()", require "" etc an, und
- sucht nach Abhängigkeiten dadrin. Die Farbcodes bedeuten:
+ Die Ausgabe zeigt alle "use *", "use parent qw()" etc an, und
+ sucht nach Abhängigkeiten dadrin. Achtung: require wird im Moment nicht
+ erkannt. Die Farbcodes bedeuten:
grün: Alles gut, das Modul ist entweder seit Ewigkeiten im perl core, oder
ist in modules/* dabei.
# listet die entsprechenden Diffs:
$ scripts/rose_auto_create_model.pl --user=<login> --diff -n --all
+* Locales auf Vollständigkeit prüfen
+
+ $ scripts/locales.pl de
+ $ scripts/locales.pl de_DE
+
* SL::DB::Helper::ALL auf Vollständigkeit prüfen
- (TODO: Mag da einer ein Script für schreiben?)
+ (TODO: Mag da einer ein Script für schreiben?
+ find SL/DB -type f | grep -v MetaSetup | grep -v Helper | grep -v Manager | sort
+ hilft, kriegt aber die Sortierung durcheinander)
* VERSION updaten
- Der git tag ist "release-<version>"
- Das DB Ipgradescript ist "release_<snake_case_version>"
-* Datenbankupgradescript "release_2_6_1" (mit aktueller Releasenummer)
- erstellen und alle Leafscripte als Abhängigkeit einsetzen. Leafscripte
- kriegt man mit
+* Nur finales Release: Datenbankupgradescript "release_2_6_1" (mit aktueller
+ Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen.
+ Leafscripte kriegt man mit
$ scripts/dbupgrade2_tool.pl --nodeps
-* Voraussichtliches finales Releasedatum im changelog eintragen
+* Voraussichtliches Releasedatum im changelog eintragen
* Finaler Testlauf:
t/test.sh
- - Im Moment sind 4 Fehler optimal (die sind noch nicht angegangen):
- o bin/mozilla/ar.pl contains at least 190 html tags.
- o bin/mozilla/ic.pl contains at least 130 html tags.
- o bin/mozilla/ap.pl contains at least 183 html tags.
- o bin/mozilla/admin.pl DOES NOT use proper system or exec calls
- - Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus.
- TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde.
- TODO: Dokumeniteren wie der Releasemanager sich so eine DB baut, die
- sollten vor einem Release zumindest durchlaufen.
- TODO: Evtl eine Klasse von Releasetests einführen)
+ Siehe oben für mögliche Ergebnisse.
* Alle Änderungen einchecken.
2. RELEASE
+==========
* Annotated tag erstellen und pushen
$ git tag -a release-2.6.1
- $ git push origin tgs/release-2.6.1
+ $ git push origin tags/release-2.6.1
* Tarball erstellen
* Alles auf Sourceforge hochladen
+* Auf Sourceforge den Standarddownloadlink setzen
+
* Releasemessages schreiben für folgende Ziele:
- lx-office.org: deutsch, prosa, formell
- - freshmeat.net: englisch, max 600 zeichen, technische stichpunkte aus dem changelog
+ - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net)
- mailinglisten: deutsch, freitext, informell
* Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
-* Webseite aktualisieren, Releasemessages auf freshmeat und Mailinglisten posten
+* Webseite aktualisieren, Releasemessages auf freecode und Mailinglisten posten
+
+
+3. POST RELEASE
+===============
+
+* Im Bugzilla die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können.
+
+* Nach einem Major Release alle Bugs die den Milestone hatten und nicht gefixt wurden zurücksetzen