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: Release Candidates Zeitplan).
20 1. KONSISTENZ DES PROGRAMMS
21 ===========================
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)
35 * Testinstallation aus dem git mit neuer auth Datenbank.
37 - Änderungen die die auth Systeme betreffen zerreissen gerne mal die initiale
40 * Testupgrade auf einer Vorversion.
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.
46 * Freeze auf der Mailingliste ansagen.
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)
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
60 - Sollten noch schwere Probleme existieren, Release verschieben.
62 * Changelog aktualisieren.
64 - Im Changelog sollten sämtliche behobenen Bugs seit der letzten Version
67 Beispiel für semiautomatisches bearbeiten:
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:
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
80 o Individuelle Abfrage
81 + geändert zwischen <letztes Releasedatum> und <heute+1>
84 + Komponente ist Lx-Office ERP
85 o Spalten: nur Zusammenfassung
86 o sortieren nach Ticketnummer
87 o rest weiter ab copy&paste
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)
94 Achtung: trac benutzt Datum 00:00:00 als obere Grenze, dass heisst, immer
95 einen Tag mehr angeben.
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.
101 * Perlabhängigkeiten prüfen
103 $ scripts/find-use.pl
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:
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.
115 Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht
118 1. Wo kriegt man das Modul her?
121 - cpan devel version?
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.
127 3. Das Modul in SL/InstallationCheck.pm eintragen. Testen.
129 4. Das Modul in der Installationsanleitung eintragen.
131 * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen.
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.
139 * doc/Lx-Office-Dokumentation.pdf erstellen
142 * scripts/rose_auto_create_model.pl update machen.
144 Das ist nicht ganz einfach, dafür gibt es keinen einfachen Knopf. Folgende
145 Constraints sollten eingehalten werden:
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
159 Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
161 # listet alle Dateien in denen sich etwas Ändern würde
162 $ scripts/rose_auto_create_model.pl --user=<login> -n --all
164 # listet die entsprechenden Diffs:
165 $ scripts/rose_auto_create_model.pl --user=<login> --diff -n --all
167 * Locales auf Vollständigkeit prüfen
169 $ scripts/locales.pl de
171 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
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)
179 Zu den Versionierungen vor 3.0.0:
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>"
187 Zu den Versionierungen ab 3.0.0:
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>"
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
199 $ scripts/dbupgrade2_tool.pl --nodeps
201 * Voraussichtliches Releasedatum im changelog eintragen
207 Siehe oben für mögliche Ergebnisse.
209 * Alle Änderungen einchecken.
216 * Annotated tag erstellen und pushen
218 $ git tag -a release-2.6.1
219 $ git push origin tags/release-2.6.1
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
227 (der trailing slash bei prefix ist wichtig)
229 * Tarball testen, wird das richtig entpackt?
231 * SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
233 * Alles auf Sourceforge hochladen
235 * Auf Sourceforge den Standarddownloadlink setzen
237 * Releasemessages schreiben für folgende Ziele:
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
243 * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
245 * Webseite aktualisieren, Releasemessages auf freecode und Mailinglisten posten
251 * Im Bugzilla die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können.
253 * Nach einem Major Release alle Bugs die den Milestone hatten und nicht gefixt wurden zurücksetzen