X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Frelease_management.txt;h=36d4c1688cfc68c52807e5572c033924b66ed9bd;hb=d1564e8aa44f920d0c9ddf08141417f0deb89ba6;hp=a31e13a0b724a7f98500699485dff0826a1da63c;hpb=48963f462b5fff937438ca93bcc537d78e454f30;p=kivitendo-erp.git diff --git a/doc/release_management.txt b/doc/release_management.txt index a31e13a0b..36d4c1688 100644 --- a/doc/release_management.txt +++ b/doc/release_management.txt @@ -13,13 +13,37 @@ als freundliche Checkliste zum ausdrucken und erweitern. * 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 @@ -36,8 +60,20 @@ als freundliche Checkliste zum ausdrucken und erweitern. * 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 | head -1 + o Alle Bugs seit dem mit der Buzilla advanced search suchen: + + Bugs changed + + Only bugs changed between 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. @@ -46,8 +82,9 @@ als freundliche Checkliste zum ausdrucken und erweitern. $ 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. @@ -107,9 +144,16 @@ als freundliche Checkliste zum ausdrucken und erweitern. # listet die entsprechenden Diffs: $ scripts/rose_auto_create_model.pl --user= --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 @@ -121,39 +165,31 @@ als freundliche Checkliste zum ausdrucken und erweitern. - Der git tag ist "release-" - Das DB Ipgradescript ist "release_" -* 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 @@ -169,12 +205,22 @@ als freundliche Checkliste zum ausdrucken und erweitern. * 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