Pflichtenheftversion nach Änderung Basisdaten invalidieren
[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 * Testlauf mit t/test.pl
24   Benutzer und Mandant muss hierfür entsprechend in kivitendo.conf > Abschnitt testing
25   konfiguriert sein.
26
27   - Im Moment sind 3 Fehler optimal (die sind noch nicht angegangen):
28     o  bin/mozilla/ic.pl contains at least 123 html tags.
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)
34
35 * Testinstallation aus dem git mit neuer auth Datenbank.
36
37   - Änderungen, die die auth Systeme betreffen, zerreissen gerne mal die initiale
38     Installation.
39
40 * Testupgrade auf einer Vorversion.
41
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.
45
46 * Freeze auf der Mailingliste ansagen.
47
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)
51
52 * Status Trac
53
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
59     werden.
60   - Sollten noch schwere Probleme existieren, Release verschieben.
61
62 * Changelog aktualisieren.
63
64   - Im Changelog sollten sämtliche behobenen Bugs seit der letzten Version
65     aufgeführt sein.
66
67     Beispiel für semiautomatisches bearbeiten:
68
69     o Letztes Releasedatum: git log --pretty=format:%cd <release-tag> | head -1
70     o Alle Bugs seitdem mit Trac suchen ("Tickets anzeigen" ->
71       "Individuelle Abfrage"):
72       + Status: [X] closed
73       + Geändert: zwischen <letztes Releasedatum> und <heute>
74       + Lösung: [x] behoben  [x] Duplikat  [x] funktioniert-bei-mir
75       + Komponente: ist kivitendo ERP
76       + Spalten: [x] Zusammenfassung
77     o sortieren nach Ticketnummer
78     o copy&paste in eine Datei
79     o perl -pale '$_="  - Bugfix $F[0]: @F[1..$#F]"' oder awk/sed drüber
80
81     Achtung: Trac hat im Moment noch Probleme, so dass Bugs zum Teil mit nicht
82     existenten Lösungen geschlossen werden.  Besser ist es, sich die Lösung als
83     eigene Spalte anzeigen zu lassen, die Lösungen zu filtern, die nicht
84     erwünscht sind, und den Rest zu formatieren (TODO: Script erweitern)
85
86     Achtung: Trac benutzt Datum 00:00:00 als obere Grenze, dass heißt, immer
87     einen Tag mehr angeben.
88
89   - Ausserdem einmal durch das git scrollen und sinnvolle größere Änderungen
90     ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach
91     nur noch inkrementell.
92
93 * Perlabhängigkeiten prüfen
94
95   $ scripts/find-use.pl
96
97   Die Ausgabe zeigt alle "use *", "use parent qw()" etc an, und
98   sucht nach Abhängigkeiten dadrin. Achtung: require wird im Moment nicht
99   erkannt. Die Farbcodes bedeuten:
100
101   grün: Alles gut, das Modul ist entweder seit Ewigkeiten im Perl core, oder
102         ist in modules/* dabei.
103   gelb: Das Modul ist nach 5.8.0 in den Core gekommen, oder steht ordnungsgemäß
104         im InstallationCheck.pm
105   rot:  Noch nie gesehen das Modul. Muss eingepflegt werden.
106
107   Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht
108   werden:
109
110   1. Wo kriegt man das Modul her?
111     - Debian-Paket?
112     - CPAN-Paket?
113     - CPAN-Devel-Version?
114
115   2. Welche Mindestversion funktioniert sicher?
116     - zumindest deine aktuelle. Ansonsten auch mal im CPAN Changelog schauen, wie
117       alt die ist, und was alles dazugekommen ist.
118
119   3. Das Modul in SL/InstallationCheck.pm eintragen. Testen.
120
121   4. Das Modul in der Installationsanleitung eintragen.
122
123 * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen.
124
125   Upgrade muss mindestens folgende Informationen enthalten:
126   - Neue Pakete und Abhängigkeiten
127   - Alles was nicht in der normalen Updatedoku steht und nötig ist, um eine
128     Version bis zum erfolgreichen Login der neuen Version zu kriegen.
129   - Bekannte Probleme die im testing auftraten dokumentieren.
130
131 * doc/kivitendo-Dokumentation.pdf erstellen
132   - ggf. muss hier noch dobudish installiert werden, s.a. Entwicklerdokumentation ->
133     Dokumentation erstellen. Ansonsten reicht dieser Aufruf:
134   $ scripts/build_doc.sh
135
136 * scripts/rose_auto_create_model.pl update machen.
137
138   Das ist nicht ganz einfach, dafür gibt es keinen einfachen Knopf. Folgende
139   Constraints sollten eingehalten werden:
140
141   - Alle Datenbank Upgrades seit der letzten Version müssen eingepflegt werden.
142   - Alle noch nicht normalisierten Tabellen müssen weiterhin ignoriert werden.
143   - Alle Felder, die von der crm, von bob, von lx-cars oder sonstwo in die
144     Datenbank gekommen sind, müssen ignoriert werden.
145   - Wenn die Reihenfolge der Spalten in der Datenbank moniert wird, dann sollte
146     das auch ignoriert werden. (Kann passieren, wenn DB Upgrades in
147     verschiedener Reihenfolge eingespielt werden.)
148   - Wenn Metastatements dazukommen, wie zum Beispiel
149     "allow_inline_column_values => 1," dann ist die Ausgabe der neusten
150     Rose::DB::Object Version zu wählen die kompatibel zu älteren Versionen
151     bleibt.
152
153   Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
154
155   # listet alle Dateien in denen sich etwas ändern würde
156   $ scripts/rose_auto_create_model.pl --client=<name-or-id> -n --all
157
158   # listet die entsprechenden Diffs:
159   $ scripts/rose_auto_create_model.pl --client=<name-or-id> --diff -n --all
160
161 * Locales auf Vollständigkeit prüfen
162
163   $ scripts/locales.pl de
164
165 * SL::DB::Helper::ALL auf Vollständigkeit prüfen
166
167   (TODO: Mag da einer ein Script für schreiben?
168      find SL/DB -type f | grep -v MetaSetup | grep -v Helper | grep -v Manager | sort
169    hilft, kriegt aber die Sortierung durcheinander)
170
171 * VERSION updaten
172
173   Zu den Versionierungen ab 3.0.0:
174
175   - Das Programm heißt kivitendo (alles klein)
176   - Das Paket heißt kivitendo
177   - Der Standardpfad ist kivitendo-<version>
178   - Der git tag ist "release-<version>"
179   - Das DB Upgradescript ist "release_<snake_case_version>"
180   - Die Datei VERSION anpassen
181
182   Zu den Versionierungen vor 3.0.0:
183
184   - Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen)
185   - Das Paket heißt lx-office-erp (klein, plus "-erp")
186   - Der Standardpfad ist lxoffice-erp-<version> (fehlender Bindestrich)
187   - Der git tag ist "release-<version>"
188   - Das DB Upgradescript ist "release_<snake_case_version>"
189
190 * Nur finales Release: Datenbankupgradescript "release_3_0_0" (mit aktueller
191   Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen.
192   Leafscripte kriegt man mit
193
194   $ scripts/dbupgrade2_tool.pl --nodeps
195
196 * Voraussichtliches Releasedatum im changelog eintragen
197
198 * Finaler Testlauf:
199
200   t/test.pl
201
202   Siehe oben für mögliche Ergebnisse.
203
204 * Alle Änderungen einchecken.
205
206
207
208 2. RELEASE
209 ==========
210
211 * Annotated tag erstellen und pushen
212
213   $ git tag -a release-3.0.0
214   $ git push origin tags/release-3.0.0
215
216 * Tarball erstellen
217
218   Commits mit Tags können von github als Archiv heruntergeladen werden:
219   https://github.com/kivitendo/kivitendo-erp/releases
220
221 * Tarball testen, wird das richtig entpackt?
222
223 * SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
224
225 * Alles auf Sourceforge hochladen
226
227 * Auf Sourceforge den Standarddownloadlink setzen
228
229 * Releasemessages schreiben für folgende Ziele:
230
231   - kivitendo.de: deutsch, prosa, formell
232   - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net)
233   - Mailinglisten: deutsch, freitext, informell
234
235 * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
236
237 * Webseite aktualisieren, Releasemessages auf freecode und Mailinglisten posten
238
239
240 3. POST RELEASE
241 ===============
242
243 * Im Trac die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden
244   können.
245
246 * Nach einem Major Release alle Bugs, die den Milestone hatten und nicht gefixt
247   wurden, zurücksetzen