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 t/test.sh
  24
  25   - Im Moment sind 4 Fehler optimal (die sind noch nicht angegangen):
  26     o  bin/mozilla/ar.pl contains at least 190 html tags.
  27     o  bin/mozilla/ic.pl contains at least 130 html tags.
  28     o  bin/mozilla/ap.pl contains at least 183 html tags.
  29     o  bin/mozilla/admin.pl DOES NOT use proper system or exec calls
  30   - Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus.
  31     TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde.
  32     TODO: Dokumeniteren wie der Releasemanager sich so eine DB baut, die
  33           sollten vor einem Release zumindest durchlaufen.
  34     TODO: Evtl eine Klasse von Releasetests einführen)
  35
  36 * Testinstallation aus dem git mit neuer auth Datenbank.
  37
  38   - Änderungen die die auth Systeme betreffen zerreissen gerne mal die initiale
  39     Installation.
  40
  41 * Testupgrade auf einer Vorversion.
  42
  43   - Dito nur mit Upgradescripten. Fehlerhafte Abhängigkeiten können dazu
  44     führen, dass Upgradescripte nicht in der richtigen Reihenfolge ausgeführt
  45     werden, was bei inkrementellem Testen nicht auffällt.
  46
  47 * Freeze auf der Mailingliste ansagen.
  48
  49   - Featurefreeze für beta
  50   - Commitfreeze für finales Release
  51
  52 * Status Bugzilla
  53
  54   - Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr
  55     offen sein.
  56   - Neue Bugs seit dem Bugsprint müssen bewertet, gegebenenfalls behoben
  57     werden.
  58   - Sollten noch schwere Probleme existieren, Release verschieben.
  59
  60 * Changelog aktualisieren.
  61
  62   - Im Changelog sollten sämtliche behobenen Bugs seit der letzten Version
  63     aufgeführt sein.
  64
  65     Beispiel für semiautomatisches bearbeiten:
  66
  67     o Letztes Releasedatum: git log --pretty=format:%cd <release-tag> | head -1
  68     o Alle Bugs seit dem mit der Buzilla advanced search suchen:
  69       + Bugs changed
  70       + Only bugs changed between <letztes Releasedatum> and Now
  71       + where only one or more of the following changed: "Resolution"
  72       + and the new value was: "FIXED"
  73     o columns ändern auf nur "Full Summary"
  74     o copy&paste in eine Datei
  75     o perl -pale '$_="  - Bugfix $F[0]: @F[1..$#F]"' oder awk/sed drüber
  76
  77   - Ausserdem einmal durch das git scrollen und sinnvolle grössere Änderungen
  78     ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach
  79     nur noch inkrementell.
  80
  81 * Perlabhängigkeiten prüfen
  82
  83   $ scripts/find-use.pl
  84
  85   Die Ausgabe zeigt alle "use *", "use parent qw()" etc an, und
  86   sucht nach Abhängigkeiten dadrin. Achtung: require wird im Moment nicht
  87   erkannt. Die Farbcodes bedeuten:
  88
  89   grün: Alles gut, das Modul ist entweder seit Ewigkeiten im perl core, oder
  90         ist in modules/* dabei.
  91   gelb: Das Modul ist nach 5.8.0 in den core gekommen, oder steht ordnungsgemäß
  92         im InstallationCheck.pm
  93   rot:  Noch nie gesehen das Modul. muss eingepflegt werden.
  94
  95   Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht
  96   werden:
  97
  98   1. Wo kriegt man das Modul her?
  99     - debian paket?
 100     - cpan paket?
 101     - cpan devel version?
 102
 103   2. Welche Mindestversion funktioniert sicher?
 104     - zuindest deine aktuelle. ansonsten auch mal im cpan changelog schauen wie
 105       alt die ist, und was alles dazugekommen ist.
 106
 107   3. Das Modul in SL/InstallationCheck.pm eintragen. Testen.
 108
 109   4. Das Modul in der Installationsanleitung eintragen.
 110
 111 * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen.
 112
 113   Upgrade muss mindestens folgende Informationen enthalten:
 114   - Neue Pakete und Abhängigkeiten
 115   - Alles was nicht in der normalen Updatedoku steht und nötig ist, um eine
 116     Version bis zum erfolgreichen Login der neuen Version zu kriegen.
 117   - Bekannte Probleme die im testing auftraten dokumentieren.
 118
 119 * doc/Lx-Office-Dokumentation.pdf erstellen
 120  (TODO: commands)
 121
 122 * scripts/rose_auto_create_model.pl update machen.
 123
 124   Das ist nicht ganz einfach, dafür gibt es keinen einfachen Knopf. Folgende
 125   Constraints sollten eingehalten werden:
 126
 127   - Alle Datenbank Upgrades seit der letzten Version müssen eingepflegt werden.
 128   - Alle noch nicht normalisierten Tabellen müssen weiterhin ignoriert werden.
 129   - Alle Felder die von der crm, von bob, von lx-cars oder sonstwo in die
 130     Datenbank gekommen sind, müssen ignoriert werden.
 131   - Wenn die Reihenfolge der Spalten in der Datenbank moniert wird, dann sollte
 132     das auch ignoriert werden. (Kann passieren, wenn DB Upgrades in
 133     verschiedener Reihenfolge eingespielt werden.)
 134   - Wenn Metastatements dazukommen, wie zum Beispiel
 135     "allow_inline_column_values => 1," dann ist die Ausgabe der neusten
 136     Rose::DB::Object Version zu wählen die kompatibel zu älteren Versionen
 137     bleibt.
 138
 139   Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
 140
 141   # listet alle Dateien in denen sich etwas Ändern würde
 142   $ scripts/rose_auto_create_model.pl --user=<login> -n --all
 143
 144   # listet die entsprechenden Diffs:
 145   $ scripts/rose_auto_create_model.pl --user=<login> --diff -n --all
 146
 147 * Locales auf Vollständigkeit prüfen
 148
 149   $ scripts/locales.pl de
 150   $ scripts/locales.pl de_DE
 151
 152 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
 153
 154   (TODO: Mag da einer ein Script für schreiben?
 155      find SL/DB -type f | grep -v MetaSetup | grep -v Helper | grep -v Manager | sort
 156    hilft, kriegt aber die Sortierung durcheinander)
 157
 158 * VERSION updaten
 159
 160   Zu den Versionierungen:
 161
 162   - Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen)
 163   - Das Paket heißt lx-office-erp (klein, plus "-erp")
 164   - Der Standardpfad ist lxoffice-erp-<version> (fehlender Bindestrich)
 165   - Der git tag ist "release-<version>"
 166   - Das DB Ipgradescript ist "release_<snake_case_version>"
 167
 168 * Nur finales Release: Datenbankupgradescript "release_2_6_1" (mit aktueller
 169   Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen.
 170   Leafscripte kriegt man mit
 171
 172   $ scripts/dbupgrade2_tool.pl --nodeps
 173
 174 * Voraussichtliches Releasedatum im changelog eintragen
 175
 176 * Finaler Testlauf:
 177
 178   t/test.sh
 179
 180   Siehe oben für mögliche Ergebnisse.
 181
 182 * Alle Änderungen einchecken.
 183
 184
 185
 186 2. RELEASE
 187 ==========
 188
 189 * Annotated tag erstellen und pushen
 190
 191   $ git tag -a release-2.6.1
 192   $ git push origin tags/release-2.6.1
 193
 194 * Tarball erstellen
 195
 196   $ git archive --format=tar --remote=<master repo>        \
 197         --prefix=lxoffice-erp-2.6.1/ release-2.6.1 | gzip  \
 198         > lx-office-erp-2.6.1.tar.gz
 199
 200   (der trailing slash bei prefix ist wichtig)
 201
 202 * Tarball testen, wird das richtig entpackt?
 203
 204 * SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
 205
 206 * Alles auf Sourceforge hochladen
 207
 208 * Auf Sourceforge den Standarddownloadlink setzen
 209
 210 * Releasemessages schreiben für folgende Ziele:
 211
 212   - lx-office.org: deutsch, prosa, formell
 213   - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net)
 214   - mailinglisten: deutsch, freitext, informell
 215
 216 * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
 217
 218 * Webseite aktualisieren, Releasemessages auf freecode und Mailinglisten posten
 219
 220
 221 3. POST RELEASE
 222 ===============
 223
 224 * Im Bugzilla die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können.
 225
 226 * Nach einem Major Release alle Bugs die den Milestone hatten und nicht gefixt wurden zurücksetzen