1 Dieses Dokument listet die Arbeiten die für ein Lx-Office Release nötig sind,
2 als freundliche Checkliste zum ausdrucken und erweitern.
7 * Etwa zwei Monate vor dem Release gibt es meistens einen Bugsprint.
9 * Nach dem Bugsprint sollten alle Bugs die noch gefixt werden müssen mit einem
10 Target versehen werden.
12 * Neue Bugs nach dem Bugsprint werden später separat behandelt.
14 * Etwa einen Monat vor dem Release wird eine Beta herausgegeben.
16 * (TODO: Reease Candidates Zeitplan).
20 1. KONSISTENZ DES PROGRAMMS
21 ===========================
23 * Freeze auf der Mailingliste ansagen.
25 - Featurefreeze für beta
26 - Commitfreeze für finales Release
30 - Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr
32 - Neue Bugs seit dem Bugsprint müssen bewertet, gegebenenfalls behoben
34 - Sollten noch schwere Probleme existieren, Release verschieben.
36 * Changelog aktualisieren.
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.
45 * Perlabhängigkeiten prüfen
49 Die Ausgabe zeigt alle "use *", "use parent qw()", require "" etc an, und
50 sucht nach Abhängigkeiten dadrin. Die Farbcodes bedeuten:
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.
58 Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht
61 1. Wo kriegt man das Modul her?
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.
70 3. Das Modul in SL/InstallationCheck.pm eintragen. Testen.
72 4. Das Modul in der Installationsanleitung eintragen.
74 * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen.
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.
82 * doc/Lx-Office-Dokumentation.pdf erstellen
85 * scripts/rose_auto_create_model.pl update machen.
87 Das ist nicht ganz einfach, dafür gibt es keinen einfachen Knopf. Folgende
88 Constraints sollten eingehalten werden:
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
102 Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
104 # listet alle Dateien in denen sich etwas Ändern würde
105 $ scripts/rose_auto_create_model.pl --user=<login> -n --all
107 # listet die entsprechenden Diffs:
108 $ scripts/rose_auto_create_model.pl --user=<login> --diff -n --all
110 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
112 (TODO: Mag da einer ein Script für schreiben?)
116 Zu den Versionierungen:
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>"
124 * Datenbankupgradescript "release_2_6_1" (mit aktueller Releasenummer)
125 erstellen und alle Leafscripte als Abhängigkeit einsetzen. Leafscripte
128 $ scripts/dbupgrade2_tool.pl --nodeps
130 * Voraussichtliches finales Releasedatum im changelog eintragen
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)
147 * Alle Änderungen einchecken.
153 * Annotated tag erstellen und pushen
155 $ git tag -a release-2.6.1
156 $ git push origin tgs/release-2.6.1
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
164 (der trailing slash bei prefix ist wichtig)
166 * Tarball testen, wird das richtig entpackt?
168 * SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
170 * Alles auf Sourceforge hochladen
172 * Releasemessages schreiben für folgende Ziele:
174 - lx-office.org: deutsch, prosa, formell
175 - freshmeat.net: englisch, max 600 zeichen, technische stichpunkte aus dem changelog
176 - mailinglisten: deutsch, freitext, informell
178 * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
180 * Webseite aktualisieren, Releasemessages auf freshmeat und Mailinglisten posten