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 ae937bc..eb5cd2a 100644 (file)
--- a/doc/release_management.txt
+++ b/doc/release_management.txt
@@ -24,7 +24,7 @@ als freundliche Checkliste zum Ausdrucken und Erweitern.
   Benutzer und Mandant muss hierfür entsprechend in kivitendo.conf > Abschnitt testing
   konfiguriert sein.
 
-  - Im Moment sind 3 Fehler optimal (die sind noch nicht angegangen):
+  - 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.
@@ -118,7 +118,7 @@ als freundliche Checkliste zum Ausdrucken und Erweitern.
 
   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.
 
@@ -129,7 +129,9 @@ als freundliche Checkliste zum Ausdrucken und Erweitern.
   - Bekannte Probleme die im testing auftraten dokumentieren.
 
 * doc/kivitendo-Dokumentation.pdf erstellen
- (TODO: commands)
+  - 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.
 
@@ -158,6 +160,7 @@ als freundliche Checkliste zum Ausdrucken und Erweitern.
 
 * Locales auf Vollständigkeit prüfen
 
+  $ scripts/locales.pl en
   $ scripts/locales.pl de
 
 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
@@ -175,6 +178,7 @@ als freundliche Checkliste zum Ausdrucken und Erweitern.
   - 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:
 
@@ -190,11 +194,16 @@ als freundliche Checkliste zum Ausdrucken und Erweitern.
 
   $ 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:
 
-  t/test.sh
+  t/test.pl
 
   Siehe oben für mögliche Ergebnisse.
 
@@ -205,8 +214,16 @@ als freundliche Checkliste zum Ausdrucken und Erweitern.
 2. RELEASE
 ==========
 
+* 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
+
+
 * Annotated tag erstellen und pushen
 
+  # 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
 
@@ -215,18 +232,9 @@ als freundliche Checkliste zum Ausdrucken und Erweitern.
   Commits mit Tags können von github als Archiv heruntergeladen werden:
   https://github.com/kivitendo/kivitendo-erp/releases
 
-* Tarball testen, wird das richtig entpackt?
-
-* SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
-
-* Alles auf Sourceforge hochladen
-
-* Auf Sourceforge den Standarddownloadlink setzen
-
 * Releasemessages schreiben für folgende Ziele:
 
   - 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