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