Merge branch 'master' of github.com:kivitendo/kivitendo-erp

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

diff --git a/doc/release_management.txt b/doc/release_management.txt
index df6ba34..533915f 100644 (file)
--- a/doc/release_management.txt
+++ b/doc/release_management.txt
@@ -28,7 +28,7 @@ als freundliche Checkliste zum ausdrucken und erweitern.
     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.
     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
+    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)
 
           sollten vor einem Release zumindest durchlaufen.
     TODO: Evtl eine Klasse von Releasetests einführen)
 


@@ -46,9 +46,10 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 * 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
     offen sein, ist aber unrealistisch. Die noch offenen Bugs müssen bewertet
 
   - Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr
     offen sein, ist aber unrealistisch. Die noch offenen Bugs müssen bewertet


@@ -66,26 +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
 

-    Das gleiche für trac:
-    o Individuelle Abfrage
-      + geändert zwischen <letztes Releasedatum> und <heute>
-      + Status closed
-      + Lösung behobena
-      + Komponente ist Lx-Office ERP
-    o Spalten: nur Zusammenfassung
-    o sortieren nach Ticketnummer
-    o rest weiter ab copy&paste
+    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össere Änderungen
+  - 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.
 


@@ -97,22 +98,22 @@ als freundliche Checkliste zum ausdrucken und erweitern.
   sucht nach Abhängigkeiten dadrin. Achtung: require wird im Moment nicht
   erkannt. Die Farbcodes bedeuten:
 
   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.


@@ -127,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.


@@ -167,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
 


@@ -198,14 +207,14 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
 * Annotated tag erstellen und pushen
 
 
 * Annotated tag erstellen und pushen
 

-  $ git tag -a release-2.6.1
-  $ git push origin tags/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)
 


@@ -219,9 +228,9 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
 * Releasemessages schreiben für folgende Ziele:
 
 
 * Releasemessages schreiben für folgende Ziele:
 

-  - lx-office.org: deutsch, prosa, formell
+  - kivitendo.de: deutsch, prosa, formell

   - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net)
   - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net)

-  - mailinglisten: deutsch, freitext, informell
+  - Mailinglisten: deutsch, freitext, informell

 
 * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
 
 
 * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
 


@@ -231,6 +240,6 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 3. POST RELEASE
 ===============
 
 3. POST RELEASE
 ===============
 

-* Im Bugzilla die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können.
+* 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
 
 * Nach einem Major Release alle Bugs die den Milestone hatten und nicht gefixt wurden zurücksetzen