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