X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Frelease_management.txt;h=eb5cd2a8b9930b6885553653967fe1341dabf8d6;hb=24af0d9994b2d7e00d740b6bb6e698c68ebc96a4;hp=078f92bf87a29ccefb14353ac00f010c1976b2c4;hpb=ec1daa3dd64bb3083c8a5d0a4b1854143c33e721;p=kivitendo-erp.git diff --git a/doc/release_management.txt b/doc/release_management.txt index 078f92bf8..eb5cd2a8b 100644 --- a/doc/release_management.txt +++ b/doc/release_management.txt @@ -1,5 +1,5 @@ Dieses Dokument listet die Arbeiten die für ein Lx-Office Release nötig sind, -als freundliche Checkliste zum ausdrucken und erweitern. +als freundliche Checkliste zum Ausdrucken und Erweitern. 0. IM VORFELD ============= @@ -13,22 +13,48 @@ als freundliche Checkliste zum ausdrucken und erweitern. * Etwa einen Monat vor dem Release wird eine Beta herausgegeben. -* (TODO: Reease Candidates Zeitplan). +* (TODO: Release Candidates Zeitplan). 1. KONSISTENZ DES PROGRAMMS =========================== +* Testlauf mit t/test.pl + Benutzer und Mandant muss hierfür entsprechend in kivitendo.conf > Abschnitt testing + konfiguriert sein. + + - Im Moment sind 3 Fehler optional (die sind noch nicht angegangen): + o bin/mozilla/ic.pl contains at least 123 html tags. + - Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus. + TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde. + TODO: Dokumentieren wie der Releasemanager sich so eine DB baut, die + sollten vor einem Release zumindest durchlaufen. + TODO: Evtl eine Klasse von Releasetests einführen) + +* Testinstallation aus dem git mit neuer auth Datenbank. + + - Änderungen, die die auth Systeme betreffen, zerreissen gerne mal die initiale + Installation. + +* Testupgrade auf einer Vorversion. + + - Dito nur mit Upgradescripten. Fehlerhafte Abhängigkeiten können dazu + führen, dass Upgradescripte nicht in der richtigen Reihenfolge ausgeführt + werden, was bei inkrementellem Testen nicht auffällt. + * Freeze auf der Mailingliste ansagen. - Featurefreeze für beta - - Commitfreeze für finales Release + - Commitfreeze für finales Release (Erfahrungswerte: 1 Tag für die erste + Beta, 2-4h für jedes weitere Release, 1 Tag fürs finale Release) -* Status Bugzilla +* Status Trac - Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr - offen sein. + offen sein, ist aber unrealistisch. Die noch offenen Bugs müssen bewertet + werden. Kritische Bugs müssen behoben, weniger kritische evtl auf die + nächste Version verschoben werden. - Neue Bugs seit dem Bugsprint müssen bewertet, gegebenenfalls behoben werden. - Sollten noch schwere Probleme existieren, Release verschieben. @@ -41,16 +67,26 @@ als freundliche Checkliste zum ausdrucken und erweitern. Beispiel für semiautomatisches bearbeiten: o Letztes Releasedatum: git log --pretty=format:%cd | head -1 - o Alle Bugs seit dem mit der Buzilla advanced search suchen: - + Bugs changed - + Only bugs changed between and Now - + where only one or more of the following changed: "Resolution" - + and the new value was: "FIXED" - o columns ändern auf nur "Full Summary" + o Alle Bugs seitdem mit Trac suchen ("Tickets anzeigen" -> + "Individuelle Abfrage"): + + Status: [X] closed + + Geändert: zwischen und + + Lösung: [x] behoben [x] Duplikat [x] funktioniert-bei-mir + + Komponente: ist kivitendo ERP + + Spalten: [x] Zusammenfassung + o sortieren nach Ticketnummer o copy&paste in eine Datei o perl -pale '$_=" - Bugfix $F[0]: @F[1..$#F]"' oder awk/sed drüber - - Ausserdem einmal durch das git scrollen und sinnvolle grössere Änderungen + Achtung: Trac hat im Moment noch Probleme, so dass Bugs zum Teil mit nicht + existenten Lösungen geschlossen werden. Besser ist es, sich die Lösung als + eigene Spalte anzeigen zu lassen, die Lösungen zu filtern, die nicht + erwünscht sind, und den Rest zu formatieren (TODO: Script erweitern) + + Achtung: Trac benutzt Datum 00:00:00 als obere Grenze, dass heißt, immer + einen Tag mehr angeben. + + - Ausserdem einmal durch das git scrollen und sinnvolle größere Änderungen ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach nur noch inkrementell. @@ -58,30 +94,31 @@ als freundliche Checkliste zum ausdrucken und erweitern. $ scripts/find-use.pl - Die Ausgabe zeigt alle "use *", "use parent qw()", require "" etc an, und - sucht nach Abhängigkeiten dadrin. Die Farbcodes bedeuten: + Die Ausgabe zeigt alle "use *", "use parent qw()" etc an, und + sucht nach Abhängigkeiten dadrin. Achtung: require wird im Moment nicht + erkannt. Die Farbcodes bedeuten: - grün: Alles gut, das Modul ist entweder seit Ewigkeiten im perl core, oder + grün: Alles gut, das Modul ist entweder seit Ewigkeiten im Perl core, oder ist in modules/* dabei. - gelb: Das Modul ist nach 5.8.0 in den core gekommen, oder steht ordnungsgemäß + gelb: Das Modul ist nach 5.8.0 in den Core gekommen, oder steht ordnungsgemäß im InstallationCheck.pm - rot: Noch nie gesehen das Modul. muss eingepflegt werden. + rot: Noch nie gesehen das Modul. Muss eingepflegt werden. Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht werden: 1. Wo kriegt man das Modul her? - - debian paket? - - cpan paket? - - cpan devel version? + - Debian-Paket? + - CPAN-Paket? + - CPAN-Devel-Version? 2. Welche Mindestversion funktioniert sicher? - - zuindest deine aktuelle. ansonsten auch mal im cpan changelog schauen wie + - zumindest deine aktuelle. Ansonsten auch mal im CPAN Changelog schauen, wie alt die ist, und was alles dazugekommen ist. 3. Das Modul in SL/InstallationCheck.pm eintragen. Testen. - 4. Das Modul in der Installationsanleitung eintragen. + 4. Das Modul in der Installationsanleitung (documentation.xml) eintragen. * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen. @@ -91,8 +128,10 @@ als freundliche Checkliste zum ausdrucken und erweitern. Version bis zum erfolgreichen Login der neuen Version zu kriegen. - Bekannte Probleme die im testing auftraten dokumentieren. -* doc/Lx-Office-Dokumentation.pdf erstellen - (TODO: commands) +* doc/kivitendo-Dokumentation.pdf erstellen + - ggf. muss hier noch dobudish installiert werden, s.a. Entwicklerdokumentation -> + Dokumentation erstellen. Ansonsten reicht dieser Aufruf: + $ scripts/build_doc.sh * scripts/rose_auto_create_model.pl update machen. @@ -101,7 +140,7 @@ als freundliche Checkliste zum ausdrucken und erweitern. - Alle Datenbank Upgrades seit der letzten Version müssen eingepflegt werden. - Alle noch nicht normalisierten Tabellen müssen weiterhin ignoriert werden. - - Alle Felder die von der crm, von bob, von lx-cars oder sonstwo in die + - Alle Felder, die von der crm, von bob, von lx-cars oder sonstwo in die Datenbank gekommen sind, müssen ignoriert werden. - Wenn die Reihenfolge der Spalten in der Datenbank moniert wird, dann sollte das auch ignoriert werden. (Kann passieren, wenn DB Upgrades in @@ -113,11 +152,16 @@ als freundliche Checkliste zum ausdrucken und erweitern. Zum Prüfen was sich geändert hat eignen sich folgende Befehle: - # listet alle Dateien in denen sich etwas Ändern würde - $ scripts/rose_auto_create_model.pl --user= -n --all + # listet alle Dateien in denen sich etwas ändern würde + $ scripts/rose_auto_create_model.pl --client= -n --all # listet die entsprechenden Diffs: - $ scripts/rose_auto_create_model.pl --user= --diff -n --all + $ scripts/rose_auto_create_model.pl --client= --diff -n --all + +* Locales auf Vollständigkeit prüfen + + $ scripts/locales.pl en + $ scripts/locales.pl de * SL::DB::Helper::ALL auf Vollständigkeit prüfen @@ -127,68 +171,82 @@ als freundliche Checkliste zum ausdrucken und erweitern. * VERSION updaten - Zu den Versionierungen: + Zu den Versionierungen ab 3.0.0: + + - Das Programm heißt kivitendo (alles klein) + - Das Paket heißt kivitendo + - Der Standardpfad ist kivitendo- + - Der git tag ist "release-" + - Das DB Upgradescript ist "release_" + - Die Datei VERSION anpassen + + Zu den Versionierungen vor 3.0.0: - Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen) - Das Paket heißt lx-office-erp (klein, plus "-erp") - Der Standardpfad ist lxoffice-erp- (fehlender Bindestrich) - Der git tag ist "release-" - - Das DB Ipgradescript ist "release_" + - Das DB Upgradescript ist "release_" -* Nur finales Release: Datenbankupgradescript "release_2_6_1" (mit aktueller +* Nur finales Release: Datenbankupgradescript "release_3_0_0" (mit aktueller Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen. Leafscripte kriegt man mit $ scripts/dbupgrade2_tool.pl --nodeps + Wichtig: Seit 3.0.0 gibt es noch zusätzlich ein Pg-Upgrade2-auth/ Verzeichnis, welches + für die Authentifizierungsupdates benutzt wird. + + $ scripts/dbupgrade2_tool.pl --nodeps --auth-db + * Voraussichtliches Releasedatum im changelog eintragen * Finaler Testlauf: - t/test.sh + t/test.pl - - Im Moment sind 4 Fehler optimal (die sind noch nicht angegangen): - o bin/mozilla/ar.pl contains at least 190 html tags. - o bin/mozilla/ic.pl contains at least 130 html tags. - o bin/mozilla/ap.pl contains at least 183 html tags. - o bin/mozilla/admin.pl DOES NOT use proper system or exec calls - - Einige Tests setzen eine korrekt aufgesetzte Datenbank für tests voraus. - TODO: diese Tests korrekt skippen wenn keine DB gefunden wurde. - TODO: Dokumeniteren wie der Releasemanager sich so eine DB baut, die - sollten vor einem Release zumindest durchlaufen. - TODO: Evtl eine Klasse von Releasetests einführen) + Siehe oben für mögliche Ergebnisse. * Alle Änderungen einchecken. 2. RELEASE +========== + +* VERSION auf aktuelle Version setzen + - Changelog auf Tagesdatum plus Versionssnummer + - dokumentation.xml Versionsnummer anpassen + - im Dokument UPGRADE Versionsnummer anpassen + - bei der Datei VERSION Versionsnummer anpassen + * Annotated tag erstellen und pushen - $ git tag -a release-2.6.1 - $ git push origin tgs/release-2.6.1 + # falls möglich den Tag mit dem Commit von VERSION setzen (Konvention) + $ git tag -a release-3.0.0 + $ git push origin tags/release-3.0.0 * Tarball erstellen - $ git archive --format=tar --remote= \ - --prefix=lxoffice-erp-2.6.1/ release-2.6.1 | gzip \ - > lx-office-erp-2.6.1.tar.gz + Commits mit Tags können von github als Archiv heruntergeladen werden: + https://github.com/kivitendo/kivitendo-erp/releases - (der trailing slash bei prefix ist wichtig) +* Releasemessages schreiben für folgende Ziele: -* Tarball testen, wird das richtig entpackt? + - kivitendo.de: deutsch, prosa, formell + - Mailinglisten: deutsch, freitext, informell -* SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern +* Alle Releasemessages von mindestens einer Person Korrektur lesen lassen -* Alles auf Sourceforge hochladen +* Webseite aktualisieren, Releasemessages auf freecode und Mailinglisten posten -* Releasemessages schreiben für folgende Ziele: - - lx-office.org: deutsch, prosa, formell - - freshmeat.net: englisch, max 600 zeichen, technische stichpunkte aus dem changelog - - mailinglisten: deutsch, freitext, informell +3. POST RELEASE +=============== -* Alle Releasemessages von mindestens einer Person Korrektur lesen lassen +* Im Trac die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden + können. -* Webseite aktualisieren, Releasemessages auf freshmeat und Mailinglisten posten +* Nach einem Major Release alle Bugs, die den Milestone hatten und nicht gefixt + wurden, zurücksetzen