|
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 <release-tag> | head -1
|
|
o Alle Bugs seitdem mit Trac suchen ("Tickets anzeigen" ->
|
|
"Individuelle Abfrage"):
|
|
+ Status: [X] closed
|
|
+ Geändert: zwischen <letztes Releasedatum> und <heute>
|
|
+ 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=<name-or-id> -n --all
|
|
|
|
# listet die entsprechenden Diffs:
|
|
$ scripts/rose_auto_create_model.pl --client=<name-or-id> --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)
|
|
|
|
* SL::DB::Helper::ALLAuth auf Vollständigkeit prüfen
|
|
|
|
* 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-<version>
|
|
- Der git tag ist "release-<version>"
|
|
- Das DB Upgradescript ist "release_<snake_case_version>"
|
|
- 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-<version> (fehlender Bindestrich)
|
|
- Der git tag ist "release-<version>"
|
|
- Das DB Upgradescript ist "release_<snake_case_version>"
|
|
|
|
* 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
|