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: Reease 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. (TODO ist mit ein bisschen SQL Magie direkt aus der
  40     Bugzilla Datenbank holbar, diese Magie hier möglichst dokumentieren).
  41   - Ausserdem einmal durch das git scrollen und sinnvolle grössere Änderungen
  42     ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach
  43     nur noch inkrementell.
  44
  45 * Perlabhängigkeiten prüfen
  46
  47   $ scripts/find-use.pl
  48
  49   Die Ausgabe zeigt alle "use *", "use parent qw()", require "" etc an, und
  50   sucht nach Abhängigkeiten dadrin. Die Farbcodes bedeuten:
  51
  52   grün: Alles gut, das Modul ist entweder seit Ewigkeiten im perl core, oder
  53         ist in modules/* dabei.
  54   gelb: Das Modul ist nach 5.8.0 in den core gekommen, oder steht ordnungsgemäß
  55         im InstallationCheck.pm
  56   rot:  Noch nie gesehen das Modul. muss eingepflegt werden.
  57
  58   Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht
  59   werden:
  60
  61   1. Wo kriegt man das Modul her?
  62     - debian paket?
  63     - cpan paket?
  64     - cpan devel version?
  65
  66   2. Welche Mindestversion funktioniert sicher?
  67     - zuindest deine aktuelle. ansonsten auch mal im cpan changelog schauen wie
  68       alt die ist, und was alles dazugekommen ist.
  69
  70   3. Das Modul in SL/InstallationCheck.pm eintragen. Testen.
  71
  72   4. Das Modul in der Installationsanleitung eintragen.
  73
  74 * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen.
  75
  76   Upgrade muss mindestens folgende Informationen enthalten:
  77   - Neue Pakete und Abhängigkeiten
  78   - Alles was nicht in der normalen Updatedoku steht und nötig ist, um eine
  79     Version bis zum erfolgreichen Login der neuen Version zu kriegen.
  80   - Bekannte Probleme die im testing auftraten dokumentieren.
  81
  82 * doc/Lx-Office-Dokumentation.pdf erstellen
  83  (TODO: commands)
  84
  85 * scripts/rose_auto_create_model.pl update machen.
  86
  87   Das ist nicht ganz einfach, dafür gibt es keinen einfachen Knopf. Folgende
  88   Constraints sollten eingehalten werden:
  89
  90   - Alle Datenbank Upgrades seit der letzten Version müssen eingepflegt werden.
  91   - Alle noch nicht normalisierten Tabellen müssen weiterhin ignoriert werden.
  92   - Alle Felder die von der crm, von bob, von lx-cars oder sonstwo in die
  93     Datenbank gekommen sind, müssen ignoriert werden.
  94   - Wenn die Reihenfolge der Spalten in der Datenbank moniert wird, dann sollte
  95     das auch ignoriert werden. (Kann passieren, wenn DB Upgrades in
  96     verschiedener Reihenfolge eingespielt werden.)
  97   - Wenn Metastatements dazukommen, wie zum Beispiel
  98     "allow_inline_column_values => 1," dann ist die Ausgabe der neusten
  99     Rose::DB::Object Version zu wählen die kompatibel zu älteren Versionen
 100     bleibt.
 101
 102   Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
 103
 104   # listet alle Dateien in denen sich etwas Ändern würde
 105   $ scripts/rose_auto_create_model.pl --user=<login> -n --all
 106
 107   # listet die entsprechenden Diffs:
 108   $ scripts/rose_auto_create_model.pl --user=<login> --diff -n --all
 109
 110 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
 111
 112   (TODO: Mag da einer ein Script für schreiben?)
 113
 114 * VERSION updaten
 115
 116   Zu den Versionierungen:
 117
 118   - Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen)
 119   - Das Paket heißt lx-office-erp (klein, plus "-erp")
 120   - Der Standardpfad ist lxoffice-erp-<version> (fehlender Bindestrich)
 121   - Der git tag ist "release-<version>"
 122   - Das DB Ipgradescript ist "release_<snake_case_version>"
 123
 124 * Datenbankupgradescript "release_2_6_1" (mit aktueller Releasenummer)
 125   erstellen und alle Leafscripte als Abhängigkeit einsetzen. Leafscripte
 126   kriegt man mit
 127
 128   $ scripts/dbupgrade2_tool.pl --nodeps
 129
 130 * Voraussichtliches finales Releasedatum im changelog eintragen
 131
 132 * Finaler Testlauf:
 133
 134   t/test.sh
 135
 136   - Im Moment sind 4 Fehler optimal (die sind noch nicht angegangen):
 137     o  bin/mozilla/ar.pl contains at least 190 html tags.
 138     o  bin/mozilla/ic.pl contains at least 130 html tags.
 139     o  bin/mozilla/ap.pl contains at least 183 html tags.
 140     o  bin/mozilla/admin.pl DOES NOT use proper system or exec calls
 141   - Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus.
 142     TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde.
 143     TODO: Dokumeniteren wie der Releasemanager sich so eine DB baut, die
 144           sollten vor einem Release zumindest durchlaufen.
 145     TODO: Evtl eine Klasse von Releasetests einführen)
 146
 147 * Alle Änderungen einchecken.
 148
 149
 150
 151 2. RELEASE
 152
 153 * Annotated tag erstellen und pushen
 154
 155   $ git tag -a release-2.6.1
 156   $ git push origin tgs/release-2.6.1
 157
 158 * Tarball erstellen
 159
 160   $ git archive --format=tar --remote=<master repo>        \
 161         --prefix=lxoffice-erp-2.6.1/ release-2.6.1 | gzip  \
 162         > lx-office-erp-2.6.1.tar.gz
 163
 164   (der trailing slash bei prefix ist wichtig)
 165
 166 * Tarball testen, wird das richtig entpackt?
 167
 168 * SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
 169
 170 * Alles auf Sourceforge hochladen
 171
 172 * Releasemessages schreiben für folgende Ziele:
 173
 174   - lx-office.org: deutsch, prosa, formell
 175   - freshmeat.net: englisch, max 600 zeichen, technische stichpunkte aus dem changelog
 176   - mailinglisten: deutsch, freitext, informell
 177
 178 * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
 179
 180 * Webseite aktualisieren, Releasemessages auf freshmeat und Mailinglisten posten