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