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