Mahnungen: Beim Drucken Datums- und Zahlenformate von anderen Sprachen beachten

[kivitendo-erp.git] / doc / release_management.txt

diff --git a/doc/release_management.txt b/doc/release_management.txt
index 078f92b..533915f 100644 (file)
--- a/doc/release_management.txt
+++ b/doc/release_management.txt
@@ -13,22 +13,48 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
 * Etwa einen Monat vor dem Release wird eine Beta herausgegeben.
 
 
 * Etwa einen Monat vor dem Release wird eine Beta herausgegeben.
 

-* (TODO: Reease Candidates Zeitplan).
+* (TODO: Release Candidates Zeitplan).

 
 
 
 1. KONSISTENZ DES PROGRAMMS
 ===========================
 
 
 
 
 1. KONSISTENZ DES PROGRAMMS
 ===========================
 

+* Testlauf t/test.sh
+
+  - Im Moment sind 3 Fehler optimal (die sind noch nicht angegangen):
+    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: Dokumentieren 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
 * Freeze auf der Mailingliste ansagen.
 
   - Featurefreeze für beta

-  - Commitfreeze für finales Release
+  - Commitfreeze für finales Release (Erfahrungswerte: 1 Tag für die erste
+    Beta, 2-4h für jedes weitere Release, 1 Tag fürs finale Release)

 
 

-* Status Bugzilla
+* Status Trac

 
   - Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr
 
   - Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr

-    offen sein.
+    offen sein, ist aber unrealistisch. Die noch offenen Bugs müssen bewertet
+    werden. Kritische Bugs müssen behoben, weniger kritische evtl auf die
+    nächste Version verschoben werden.

   - Neue Bugs seit dem Bugsprint müssen bewertet, gegebenenfalls behoben
     werden.
   - Sollten noch schwere Probleme existieren, Release verschieben.
   - Neue Bugs seit dem Bugsprint müssen bewertet, gegebenenfalls behoben
     werden.
   - Sollten noch schwere Probleme existieren, Release verschieben.


@@ -41,16 +67,26 @@ als freundliche Checkliste zum ausdrucken und erweitern.
     Beispiel für semiautomatisches bearbeiten:
 
     o Letztes Releasedatum: git log --pretty=format:%cd <release-tag> | head -1
     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 Alle Bugs seitdem mit Trac suchen ("Tickets anzeigen" ->
+      "Individuelle Abfrage"):
+      + Status: [X] closed
+      + Geändert: zwischen <letztes Releasedatum> und <heute>
+      + Lösung: [x] behoben  [x] Duplikat  [x] funktioniert-bei-mir
+      + Komponente: ist kivitendo ERP
+      + Spalten: [x] Zusammenfassung
+    o sortieren nach Ticketnummer

     o copy&paste in eine Datei
     o perl -pale '$_="  - Bugfix $F[0]: @F[1..$#F]"' oder awk/sed drüber
 
     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
+    Achtung: Trac hat im Moment noch Probleme, sodass Bugs zum Teil mit nicht
+    existenten Lösungen geschlossen werden.  Besser ist es, sich die Lösung als
+    eigene Spalte anzeigen zu lassen, die Lösungen zu filtern, die nicht
+    erwünscht sind, und den Rest zu formatieren (TODO: Script erweitern)
+
+    Achtung: Trac benutzt Datum 00:00:00 als obere Grenze, dass heißt, immer
+    einen Tag mehr angeben.
+
+  - Ausserdem einmal durch das git scrollen und sinnvolle größere Änderungen

     ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach
     nur noch inkrementell.
 
     ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach
     nur noch inkrementell.
 


@@ -58,25 +94,26 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
   $ scripts/find-use.pl
 
 
   $ 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
+  grün: Alles gut, das Modul ist entweder seit Ewigkeiten im Perl core, oder

         ist in modules/* dabei.
         ist in modules/* dabei.

-  gelb: Das Modul ist nach 5.8.0 in den core gekommen, oder steht ordnungsgemäß
+  gelb: Das Modul ist nach 5.8.0 in den Core gekommen, oder steht ordnungsgemäß

         im InstallationCheck.pm
         im InstallationCheck.pm

-  rot:  Noch nie gesehen das Modul. muss eingepflegt werden.
+  rot:  Noch nie gesehen das Modul. Muss eingepflegt werden.

 
   Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht
   werden:
 
   1. Wo kriegt man das Modul her?
 
   Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht
   werden:
 
   1. Wo kriegt man das Modul her?

-    - debian paket?
-    - cpan paket?
-    - cpan devel version?
+    - Debian-Paket?
+    - CPAN-Paket?
+    - CPAN-Devel-Version?

 
   2. Welche Mindestversion funktioniert sicher?
 
   2. Welche Mindestversion funktioniert sicher?

-    - zuindest deine aktuelle. ansonsten auch mal im cpan changelog schauen wie
+    - zuindest deine aktuelle. ansonsten auch mal im CPAN changelog schauen, wie

       alt die ist, und was alles dazugekommen ist.
 
   3. Das Modul in SL/InstallationCheck.pm eintragen. Testen.
       alt die ist, und was alles dazugekommen ist.
 
   3. Das Modul in SL/InstallationCheck.pm eintragen. Testen.


@@ -91,7 +128,7 @@ als freundliche Checkliste zum ausdrucken und erweitern.
     Version bis zum erfolgreichen Login der neuen Version zu kriegen.
   - Bekannte Probleme die im testing auftraten dokumentieren.
 
     Version bis zum erfolgreichen Login der neuen Version zu kriegen.
   - Bekannte Probleme die im testing auftraten dokumentieren.
 

-* doc/Lx-Office-Dokumentation.pdf erstellen
+* doc/kivitendo-Dokumentation.pdf erstellen

  (TODO: commands)
 
 * scripts/rose_auto_create_model.pl update machen.
  (TODO: commands)
 
 * scripts/rose_auto_create_model.pl update machen.


@@ -119,6 +156,10 @@ als freundliche Checkliste zum ausdrucken und erweitern.
   # listet die entsprechenden Diffs:
   $ scripts/rose_auto_create_model.pl --user=<login> --diff -n --all
 
   # 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
+

 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
 
   (TODO: Mag da einer ein Script für schreiben?
 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
 
   (TODO: Mag da einer ein Script für schreiben?


@@ -127,15 +168,23 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
 * VERSION updaten
 
 
 * VERSION updaten
 

-  Zu den Versionierungen:
+  Zu den Versionierungen ab 3.0.0:
+
+  - Das Programm heißt kivitendo (alles klein)
+  - Das Paket heißt kivitendo
+  - Der Standardpfad ist kivitendo-<version>
+  - Der git tag ist "release-<version>"
+  - Das DB Upgradescript ist "release_<snake_case_version>"
+
+  Zu den Versionierungen vor 3.0.0:

 
   - Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen)
   - Das Paket heißt lx-office-erp (klein, plus "-erp")
   - Der Standardpfad ist lxoffice-erp-<version> (fehlender Bindestrich)
   - Der git tag ist "release-<version>"
 
   - Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen)
   - Das Paket heißt lx-office-erp (klein, plus "-erp")
   - Der Standardpfad ist lxoffice-erp-<version> (fehlender Bindestrich)
   - Der git tag ist "release-<version>"

-  - Das DB Ipgradescript ist "release_<snake_case_version>"
+  - Das DB Upgradescript ist "release_<snake_case_version>"

 
 

-* Nur finales Release: Datenbankupgradescript "release_2_6_1" (mit aktueller
+* Nur finales Release: Datenbankupgradescript "release_3_0_0" (mit aktueller

   Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen.
   Leafscripte kriegt man mit
 
   Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen.
   Leafscripte kriegt man mit
 


@@ -147,33 +196,25 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
   t/test.sh
 
 
   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
 
 * Alle Änderungen einchecken.
 
 
 
 2. RELEASE

+==========

 
 * Annotated tag erstellen und pushen
 
 
 * Annotated tag erstellen und pushen
 

-  $ git tag -a release-2.6.1
-  $ git push origin tgs/release-2.6.1
+  $ git tag -a release-3.0.0
+  $ git push origin tags/release-3.0.0

 
 * Tarball erstellen
 
 
 * Tarball erstellen
 

-  $ git archive --format=tar --remote=<master repo>        \
-        --prefix=lxoffice-erp-2.6.1/ release-2.6.1 | gzip  \
-        > lx-office-erp-2.6.1.tar.gz
+  $ git archive --format=tar --remote=git@vc.linet-services.de:public/lx-office-erp.git \
+        --prefix=kivitendo-erp-3.0.0/ release-3.0.0 | gzip  \
+        > kivitendo-erp-3.0.0.tgz

 
   (der trailing slash bei prefix ist wichtig)
 
 
   (der trailing slash bei prefix ist wichtig)
 


@@ -183,12 +224,22 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
 * Alles auf Sourceforge hochladen
 
 
 * Alles auf Sourceforge hochladen
 

+* Auf Sourceforge den Standarddownloadlink setzen
+

 * Releasemessages schreiben für folgende Ziele:
 
 * Releasemessages schreiben für folgende Ziele:
 

-  - lx-office.org: deutsch, prosa, formell
-  - freshmeat.net: englisch, max 600 zeichen, technische stichpunkte aus dem changelog
-  - mailinglisten: deutsch, freitext, informell
+  - kivitendo.de: deutsch, prosa, formell
+  - 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
 
 
 * 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 Trac 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