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
=============
1. KONSISTENZ DES PROGRAMMS
===========================
-* Testlauf t/test.sh
+* Testlauf mit t/test.pl
+ Benutzer und Mandant muss hierfür entsprechend in kivitendo.conf > Abschnitt testing
+ konfiguriert sein.
- - Im Moment sind 3 Fehler optimal (die sind noch nicht angegangen):
- 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
+ - 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: Dokumeniteren wie der Releasemanager sich so eine DB baut, die
+ 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
+ - Änderungen, die die auth Systeme betreffen, zerreissen gerne mal die initiale
Installation.
* Testupgrade auf einer Vorversion.
* 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, ist aber unrealistisch. Die noch offenen Bugs müssen bewertet
Beispiel für semiautomatisches bearbeiten:
o Letztes Releasedatum: git log --pretty=format:%cd <release-tag> | head -1
- o Alle Bugs seit dem mit der Buzilla advanced search suchen:
- + Bugs changed
- + Only bugs changed between <letztes Releasedatum> 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 <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
- Das gleiche für trac:
- o Individuelle Abfrage
- + geändert zwischen <letztes Releasedatum> und <heute+1>
- + Status closed
- + Lösung behobena
- + Komponente ist Lx-Office ERP
- o Spalten: nur Zusammenfassung
- o sortieren nach Ticketnummer
- o rest weiter ab copy&paste
-
- Achtung: trac hat im Moment noch Probleme, so dass Bugs zum teil mit nicht
+ 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 heisst, immer
+ 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össere Änderungen
+ - 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.
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.
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.
- 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
Zum Prüfen was sich geändert hat eignen sich folgende Befehle:
- # listet alle Dateien in denen sich etwas Ã\84ndern würde
- $ scripts/rose_auto_create_model.pl --user=<login> -n --all
+ # 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 --user=<login> --diff -n --all
+ $ 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
* VERSION updaten
- 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>"
-
Zu den Versionierungen ab 3.0.0:
- Das Programm heißt kivitendo (alles klein)
- 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_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
Siehe oben für mögliche Ergebnisse.
2. RELEASE
==========
-* Annotated tag erstellen und pushen
-
- $ git tag -a release-2.6.1
- $ git push origin tags/release-2.6.1
-
-* Tarball erstellen
+* 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
- $ git archive --format=tar --remote=<master repo> \
- --prefix=lxoffice-erp-2.6.1/ release-2.6.1 | gzip \
- > lx-office-erp-2.6.1.tar.gz
- (der trailing slash bei prefix ist wichtig)
-
-* Tarball testen, wird das richtig entpackt?
+* Annotated tag erstellen und pushen
-* SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
+ # 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
-* Alles auf Sourceforge hochladen
+* Tarball erstellen
-* Auf Sourceforge den Standarddownloadlink setzen
+ Commits mit Tags können von github als Archiv heruntergeladen werden:
+ https://github.com/kivitendo/kivitendo-erp/releases
* Releasemessages schreiben für folgende Ziele:
- - lx-office.org: deutsch, prosa, formell
- - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net)
- - mailinglisten: deutsch, freitext, informell
+ - kivitendo.de: deutsch, prosa, formell
+ - Mailinglisten: deutsch, freitext, informell
* Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
3. POST RELEASE
===============
-* Im Bugzilla die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können.
+* 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
+* Nach einem Major Release alle Bugs, die den Milestone hatten und nicht gefixt
+ wurden, zurücksetzen
projects / kivitendo-erp.git / blobdiff