Merge branch 'master' of vc.linet-services.de:public/lx-office-erp
[kivitendo-erp.git] / doc / release_management.txt
index af763b3..36d4c16 100644 (file)
@@ -20,6 +20,30 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 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
@@ -58,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.
@@ -119,6 +144,11 @@ als freundliche Checkliste zum ausdrucken und erweitern.
   # 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?
@@ -147,27 +177,19 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
   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
 
@@ -183,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