Release-Management: Hinweis Versionsnummer anpassen im UPGRADE-Dokument

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

diff --git a/doc/release_management.txt b/doc/release_management.txt
index d6bda17..eb5cd2a 100644 (file)
--- a/doc/release_management.txt
+++ b/doc/release_management.txt
@@ -1,5 +1,5 @@
 Dieses Dokument listet die Arbeiten die für ein Lx-Office Release nötig sind,
 Dieses Dokument listet die Arbeiten die für ein Lx-Office Release nötig sind,

-als freundliche Checkliste zum ausdrucken und erweitern.
+als freundliche Checkliste zum Ausdrucken und Erweitern.

 
 0. IM VORFELD
 =============
 
 0. IM VORFELD
 =============


@@ -20,15 +20,41 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 1. KONSISTENZ DES PROGRAMMS
 ===========================
 
 1. KONSISTENZ DES PROGRAMMS
 ===========================
 

+* Testlauf mit t/test.pl
+  Benutzer und Mandant muss hierfür entsprechend in kivitendo.conf > Abschnitt testing
+  konfiguriert sein.
+
+  - Im Moment sind 3 Fehler optional (die sind noch nicht angegangen):
+    o  bin/mozilla/ic.pl contains at least 123 html tags.
+  - 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, so dass 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,30 +94,31 @@ 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
+    - zumindest 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.
 

-  4. Das Modul in der Installationsanleitung eintragen.
+  4. Das Modul in der Installationsanleitung (documentation.xml) eintragen.

 
 * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen.
 
 
 * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen.
 


@@ -91,8 +128,10 @@ 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
- (TODO: commands)
+* doc/kivitendo-Dokumentation.pdf erstellen
+  - ggf. muss hier noch dobudish installiert werden, s.a. Entwicklerdokumentation ->
+    Dokumentation erstellen. Ansonsten reicht dieser Aufruf:
+  $ scripts/build_doc.sh

 
 * scripts/rose_auto_create_model.pl update machen.
 
 
 * scripts/rose_auto_create_model.pl update machen.
 


@@ -101,7 +140,7 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
   - Alle Datenbank Upgrades seit der letzten Version müssen eingepflegt werden.
   - Alle noch nicht normalisierten Tabellen müssen weiterhin ignoriert werden.
 
   - Alle Datenbank Upgrades seit der letzten Version müssen eingepflegt werden.
   - Alle noch nicht normalisierten Tabellen müssen weiterhin ignoriert werden.

-  - Alle Felder die von der crm, von bob, von lx-cars oder sonstwo in die
+  - Alle Felder, die von der crm, von bob, von lx-cars oder sonstwo in die

     Datenbank gekommen sind, müssen ignoriert werden.
   - Wenn die Reihenfolge der Spalten in der Datenbank moniert wird, dann sollte
     das auch ignoriert werden. (Kann passieren, wenn DB Upgrades in
     Datenbank gekommen sind, müssen ignoriert werden.
   - Wenn die Reihenfolge der Spalten in der Datenbank moniert wird, dann sollte
     das auch ignoriert werden. (Kann passieren, wenn DB Upgrades in


@@ -113,16 +152,16 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
   Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
 
 
   Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
 

-  # listet alle Dateien in denen sich etwas Ã\84ndern würde
-  $ scripts/rose_auto_create_model.pl --user=<login> -n --all
+  # listet alle Dateien in denen sich etwas ändern würde
+  $ scripts/rose_auto_create_model.pl --client=<name-or-id> -n --all

 
   # listet die entsprechenden Diffs:
 
   # listet die entsprechenden Diffs:

-  $ scripts/rose_auto_create_model.pl --user=<login> --diff -n --all
+  $ scripts/rose_auto_create_model.pl --client=<name-or-id> --diff -n --all

 
 * Locales auf Vollständigkeit prüfen
 
 
 * Locales auf Vollständigkeit prüfen
 

+  $ scripts/locales.pl en

   $ scripts/locales.pl de
   $ scripts/locales.pl de

-  $ scripts/locales.pl de_DE

 
 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
 
 
 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
 


@@ -132,73 +171,82 @@ 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>"
+  - Die Datei VERSION anpassen
+
+  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
 
   $ scripts/dbupgrade2_tool.pl --nodeps
 
   Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen.
   Leafscripte kriegt man mit
 
   $ scripts/dbupgrade2_tool.pl --nodeps
 

+  Wichtig: Seit 3.0.0 gibt es noch zusätzlich ein Pg-Upgrade2-auth/ Verzeichnis, welches
+  für die  Authentifizierungsupdates benutzt wird.
+
+  $ scripts/dbupgrade2_tool.pl --nodeps --auth-db
+

 * Voraussichtliches Releasedatum im changelog eintragen
 
 * Finaler Testlauf:
 
 * Voraussichtliches Releasedatum im changelog eintragen
 
 * Finaler Testlauf:
 

-  t/test.sh
+  t/test.pl

 
 

-  - 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
-
-  $ git tag -a release-2.6.1
-  $ git push origin tags/release-2.6.1
-
-* Tarball erstellen
+* VERSION auf aktuelle Version setzen
+ - Changelog auf Tagesdatum plus Versionssnummer
+ - dokumentation.xml Versionsnummer anpassen
+ - im Dokument UPGRADE Versionsnummer anpassen
+ - bei der Datei VERSION Versionsnummer anpassen

 
 

-  $ 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

 
 

-  (der trailing slash bei prefix ist wichtig)
+* Annotated tag erstellen und pushen

 
 

-* Tarball testen, wird das richtig entpackt?
+  # falls möglich den Tag mit dem Commit von VERSION setzen (Konvention)
+  $ git tag -a release-3.0.0
+  $ git push origin tags/release-3.0.0

 
 

-* SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
+* Tarball erstellen

 
 

-* Alles auf Sourceforge hochladen
+  Commits mit Tags können von github als Archiv heruntergeladen werden:
+  https://github.com/kivitendo/kivitendo-erp/releases

 
 * 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
+  - 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
 
 
 3. POST RELEASE

+===============
+
+* Im Trac die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden
+  können.

 
 

-* 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