X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Frelease_management.txt;h=791d082fc06584095e3c70110a28bfb2b6be1ebb;hb=fe421d003c62d01455377bc8cc7d539317a65afe;hp=a31e13a0b724a7f98500699485dff0826a1da63c;hpb=385ffe497d79d79ff5987fe7c3116d334be12e00;p=kivitendo-erp.git

diff --git a/doc/release_management.txt b/doc/release_management.txt
index a31e13a0b..791d082fc 100644
--- a/doc/release_management.txt
+++ b/doc/release_management.txt
@@ -13,7 +13,7 @@ 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).
 
 
 
@@ -36,8 +36,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 <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 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 +58,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 +120,16 @@ 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?)
+  (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,13 +141,13 @@ als freundliche Checkliste zum ausdrucken und erweitern.
   - Der git tag ist "release-<version>"
   - Das DB Ipgradescript ist "release_<snake_case_version>"
 
-* 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:
 
@@ -149,11 +169,12 @@ als freundliche Checkliste zum ausdrucken und erweitern.
 
 
 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 +190,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