Hinweis auf experimentelles Feature im changelog für CVars von Typ

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

diff --git a/doc/release_management.txt b/doc/release_management.txt
index 8b052353e4077fd0aa1121c715001482b6ae45ec..791d082fc06584095e3c70110a28bfb2b6be1ebb 100644 (file)
--- 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).
 
 
 
@@ -58,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.
@@ -119,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
 
@@ -133,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:
 
@@ -161,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
 
@@ -181,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