doc/release_management.txt

   1 Dieses Dokument listet die Arbeiten die für ein Lx-Office Release nötig sind,
   2 als freundliche Checkliste zum Ausdrucken und Erweitern.
   3
   4 0. IM VORFELD
   5 =============
   6
   7 * Etwa zwei Monate vor dem Release gibt es meistens einen Bugsprint.
   8
   9 * Nach dem Bugsprint sollten alle Bugs die noch gefixt werden müssen mit einem
  10   Target versehen werden.
  11
  12 * Neue Bugs nach dem Bugsprint werden später separat behandelt.
  13
  14 * Etwa einen Monat vor dem Release wird eine Beta herausgegeben.
  15
  16 * (TODO: Release Candidates Zeitplan).
  17
  18
  19
  20 1. KONSISTENZ DES PROGRAMMS
  21 ===========================
  22
  23 * Testlauf mit t/test.pl
  24   Benutzer und Mandant muss hierfür entsprechend in kivitendo.conf > Abschnitt testing
  25   konfiguriert sein.
  26
  27   - Im Moment sind 3 Fehler optional (die sind noch nicht angegangen):
  28     o  bin/mozilla/ic.pl contains at least 123 html tags.
  29   - Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus.
  30     TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde.
  31     TODO: Dokumentieren wie der Releasemanager sich so eine DB baut, die
  32           sollten vor einem Release zumindest durchlaufen.
  33     TODO: Evtl eine Klasse von Releasetests einführen)
  34
  35 * Testinstallation aus dem git mit neuer auth Datenbank.
  36
  37   - Änderungen, die die auth Systeme betreffen, zerreissen gerne mal die initiale
  38     Installation.
  39
  40 * Testupgrade auf einer Vorversion.
  41
  42   - Dito nur mit Upgradescripten. Fehlerhafte Abhängigkeiten können dazu
  43     führen, dass Upgradescripte nicht in der richtigen Reihenfolge ausgeführt
  44     werden, was bei inkrementellem Testen nicht auffällt.
  45
  46 * Freeze auf der Mailingliste ansagen.
  47
  48   - Featurefreeze für beta
  49   - Commitfreeze für finales Release (Erfahrungswerte: 1 Tag für die erste
  50     Beta, 2-4h für jedes weitere Release, 1 Tag fürs finale Release)
  51
  52 * Status Trac
  53
  54   - Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr
  55     offen sein, ist aber unrealistisch. Die noch offenen Bugs müssen bewertet
  56     werden. Kritische Bugs müssen behoben, weniger kritische evtl auf die
  57     nächste Version verschoben werden.
  58   - Neue Bugs seit dem Bugsprint müssen bewertet, gegebenenfalls behoben
  59     werden.
  60   - Sollten noch schwere Probleme existieren, Release verschieben.
  61
  62 * Changelog aktualisieren.
  63
  64   - Im Changelog sollten sämtliche behobenen Bugs seit der letzten Version
  65     aufgeführt sein.
  66
  67     Beispiel für semiautomatisches bearbeiten:
  68
  69     o Letztes Releasedatum: git log --pretty=format:%cd <release-tag> | head -1
  70     o Alle Bugs seitdem mit Trac suchen ("Tickets anzeigen" ->
  71       "Individuelle Abfrage"):
  72       + Status: [X] closed
  73       + Geändert: zwischen <letztes Releasedatum> und <heute>
  74       + Lösung: [x] behoben  [x] Duplikat  [x] funktioniert-bei-mir
  75       + Komponente: ist kivitendo ERP
  76       + Spalten: [x] Zusammenfassung
  77     o sortieren nach Ticketnummer
  78     o copy&paste in eine Datei
  79     o perl -pale '$_="  - Bugfix $F[0]: @F[1..$#F]"' oder awk/sed drüber
  80
  81     Achtung: Trac hat im Moment noch Probleme, so dass Bugs zum Teil mit nicht
  82     existenten Lösungen geschlossen werden.  Besser ist es, sich die Lösung als
  83     eigene Spalte anzeigen zu lassen, die Lösungen zu filtern, die nicht
  84     erwünscht sind, und den Rest zu formatieren (TODO: Script erweitern)
  85
  86     Achtung: Trac benutzt Datum 00:00:00 als obere Grenze, dass heißt, immer
  87     einen Tag mehr angeben.
  88
  89   - Ausserdem einmal durch das git scrollen und sinnvolle größere Änderungen
  90     ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach
  91     nur noch inkrementell.
  92
  93 * Perlabhängigkeiten prüfen
  94
  95   $ scripts/find-use.pl
  96
  97   Die Ausgabe zeigt alle "use *", "use parent qw()" etc an, und
  98   sucht nach Abhängigkeiten dadrin. Achtung: require wird im Moment nicht
  99   erkannt. Die Farbcodes bedeuten:
 100
 101   grün: Alles gut, das Modul ist entweder seit Ewigkeiten im Perl core, oder
 102         ist in modules/* dabei.
 103   gelb: Das Modul ist nach 5.8.0 in den Core gekommen, oder steht ordnungsgemäß
 104         im InstallationCheck.pm
 105   rot:  Noch nie gesehen das Modul. Muss eingepflegt werden.
 106
 107   Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht
 108   werden:
 109
 110   1. Wo kriegt man das Modul her?
 111     - Debian-Paket?
 112     - CPAN-Paket?
 113     - CPAN-Devel-Version?
 114
 115   2. Welche Mindestversion funktioniert sicher?
 116     - zumindest deine aktuelle. Ansonsten auch mal im CPAN Changelog schauen, wie
 117       alt die ist, und was alles dazugekommen ist.
 118
 119   3. Das Modul in SL/InstallationCheck.pm eintragen. Testen.
 120
 121   4. Das Modul in der Installationsanleitung (documentation.xml) eintragen.
 122
 123 * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen.
 124
 125   Upgrade muss mindestens folgende Informationen enthalten:
 126   - Neue Pakete und Abhängigkeiten
 127   - Alles was nicht in der normalen Updatedoku steht und nötig ist, um eine
 128     Version bis zum erfolgreichen Login der neuen Version zu kriegen.
 129   - Bekannte Probleme die im testing auftraten dokumentieren.
 130
 131 * doc/kivitendo-Dokumentation.pdf erstellen
 132   - ggf. muss hier noch dobudish installiert werden, s.a. Entwicklerdokumentation ->
 133     Dokumentation erstellen. Ansonsten reicht dieser Aufruf:
 134   $ scripts/build_doc.sh
 135
 136 * scripts/rose_auto_create_model.pl update machen.
 137
 138   Das ist nicht ganz einfach, dafür gibt es keinen einfachen Knopf. Folgende
 139   Constraints sollten eingehalten werden:
 140
 141   - Alle Datenbank Upgrades seit der letzten Version müssen eingepflegt werden.
 142   - Alle noch nicht normalisierten Tabellen müssen weiterhin ignoriert werden.
 143   - Alle Felder, die von der crm, von bob, von lx-cars oder sonstwo in die
 144     Datenbank gekommen sind, müssen ignoriert werden.
 145   - Wenn die Reihenfolge der Spalten in der Datenbank moniert wird, dann sollte
 146     das auch ignoriert werden. (Kann passieren, wenn DB Upgrades in
 147     verschiedener Reihenfolge eingespielt werden.)
 148   - Wenn Metastatements dazukommen, wie zum Beispiel
 149     "allow_inline_column_values => 1," dann ist die Ausgabe der neusten
 150     Rose::DB::Object Version zu wählen die kompatibel zu älteren Versionen
 151     bleibt.
 152
 153   Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
 154
 155   # listet alle Dateien in denen sich etwas ändern würde
 156   $ scripts/rose_auto_create_model.pl --client=<name-or-id> -n --all
 157
 158   # listet die entsprechenden Diffs:
 159   $ scripts/rose_auto_create_model.pl --client=<name-or-id> --diff -n --all
 160
 161 * Locales auf Vollständigkeit prüfen
 162
 163   $ scripts/locales.pl en
 164   $ scripts/locales.pl de
 165
 166 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
 167
 168   (TODO: Mag da einer ein Script für schreiben?
 169      find SL/DB -type f | grep -v MetaSetup | grep -v Helper | grep -v Manager | sort
 170    hilft, kriegt aber die Sortierung durcheinander)
 171
 172 * VERSION updaten
 173
 174   Zu den Versionierungen ab 3.0.0:
 175
 176   - Das Programm heißt kivitendo (alles klein)
 177   - Das Paket heißt kivitendo
 178   - Der Standardpfad ist kivitendo-<version>
 179   - Der git tag ist "release-<version>"
 180   - Das DB Upgradescript ist "release_<snake_case_version>"
 181   - Die Datei VERSION anpassen
 182
 183   Zu den Versionierungen vor 3.0.0:
 184
 185   - Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen)
 186   - Das Paket heißt lx-office-erp (klein, plus "-erp")
 187   - Der Standardpfad ist lxoffice-erp-<version> (fehlender Bindestrich)
 188   - Der git tag ist "release-<version>"
 189   - Das DB Upgradescript ist "release_<snake_case_version>"
 190
 191 * Nur finales Release: Datenbankupgradescript "release_3_0_0" (mit aktueller
 192   Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen.
 193   Leafscripte kriegt man mit
 194
 195   $ scripts/dbupgrade2_tool.pl --nodeps
 196
 197   Wichtig: Seit 3.0.0 gibt es noch zusätzlich ein Pg-Upgrade2-auth/ Verzeichnis, welches
 198   für die  Authentifizierungsupdates benutzt wird.
 199
 200   $ scripts/dbupgrade2_tool.pl --nodeps --auth-db
 201
 202 * Voraussichtliches Releasedatum im changelog eintragen
 203
 204 * Finaler Testlauf:
 205
 206   t/test.pl
 207
 208   Siehe oben für mögliche Ergebnisse.
 209
 210 * Alle Änderungen einchecken.
 211
 212
 213
 214 2. RELEASE
 215 ==========
 216
 217 * VERSION auf aktuelle Version setzen
 218  - Changelog auf Tagesdatum plus Versionssnummer
 219  - dokumentation.xml Versionsnummer anpassen
 220  - bei der Datei VERSION Versionsnummer anpassen
 221
 222
 223 * Annotated tag erstellen und pushen
 224
 225   # falls möglich den Tag mit dem Commit von VERSION setzen (Konvention)
 226   $ git tag -a release-3.0.0
 227   $ git push origin tags/release-3.0.0
 228
 229 * Tarball erstellen
 230
 231   Commits mit Tags können von github als Archiv heruntergeladen werden:
 232   https://github.com/kivitendo/kivitendo-erp/releases
 233
 234 * Releasemessages schreiben für folgende Ziele:
 235
 236   - kivitendo.de: deutsch, prosa, formell
 237   - Mailinglisten: deutsch, freitext, informell
 238
 239 * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
 240
 241 * Webseite aktualisieren, Releasemessages auf freecode und Mailinglisten posten
 242
 243
 244 3. POST RELEASE
 245 ===============
 246
 247 * Im Trac die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden
 248   können.
 249
 250 * Nach einem Major Release alle Bugs, die den Milestone hatten und nicht gefixt
 251   wurden, zurücksetzen