Dieses Dokument listet die Arbeiten die für ein Lx-Office Release nötig sind, als freundliche Checkliste zum Ausdrucken und Erweitern. 0. IM VORFELD ============= * Etwa zwei Monate vor dem Release gibt es meistens einen Bugsprint. * Nach dem Bugsprint sollten alle Bugs die noch gefixt werden müssen mit einem Target versehen werden. * Neue Bugs nach dem Bugsprint werden später separat behandelt. * Etwa einen Monat vor dem Release wird eine Beta herausgegeben. * (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 (Erfahrungswerte: 1 Tag für die erste Beta, 2-4h für jedes weitere Release, 1 Tag fürs finale Release) * Status Trac - Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr 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. * Changelog aktualisieren. - Im Changelog sollten sämtliche behobenen Bugs seit der letzten Version aufgeführt sein. Beispiel für semiautomatisches bearbeiten: o Letztes Releasedatum: git log --pretty=format:%cd | head -1 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 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. * Perlabhängigkeiten prüfen $ scripts/find-use.pl 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 ist in modules/* dabei. 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. 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? 2. Welche Mindestversion funktioniert sicher? - 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 (documentation.xml) eintragen. * doc/UPGRADE doku aktualisieren und auf Vollständigkeit prüfen. Upgrade muss mindestens folgende Informationen enthalten: - Neue Pakete und Abhängigkeiten - Alles was nicht in der normalen Updatedoku steht und nötig ist, um eine Version bis zum erfolgreichen Login der neuen Version zu kriegen. - Bekannte Probleme die im testing auftraten dokumentieren. * 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. Das ist nicht ganz einfach, dafür gibt es keinen einfachen Knopf. Folgende Constraints sollten eingehalten werden: - 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 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 verschiedener Reihenfolge eingespielt werden.) - Wenn Metastatements dazukommen, wie zum Beispiel "allow_inline_column_values => 1," dann ist die Ausgabe der neusten Rose::DB::Object Version zu wählen die kompatibel zu älteren Versionen bleibt. 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 --client= -n --all # listet die entsprechenden Diffs: $ 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 (TODO: Mag da einer ein Script für schreiben? find SL/DB -type f | grep -v MetaSetup | grep -v Helper | grep -v Manager | sort hilft, kriegt aber die Sortierung durcheinander) * VERSION updaten 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 Upgradescript ist "release_" * 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.pl 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 # 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 Commits mit Tags können von github als Archiv heruntergeladen werden: https://github.com/kivitendo/kivitendo-erp/releases * Releasemessages schreiben für folgende Ziele: - kivitendo.de: deutsch, prosa, formell - Mailinglisten: deutsch, freitext, informell * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen * Webseite aktualisieren, Releasemessages auf freecode und Mailinglisten posten 3. POST RELEASE =============== * Im Trac die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können. * Nach einem Major Release alle Bugs, die den Milestone hatten und nicht gefixt wurden, zurücksetzen