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