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
=============
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):
+ - 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.
* 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.
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, sodass 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)
- 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.
- Bekannte Probleme die im testing auftraten dokumentieren.
* doc/kivitendo-Dokumentation.pdf erstellen
- (TODO: commands)
+ - 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
- 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:
$ 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
==========
+* 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
- $ git archive --format=tar --remote=git@vc.linet-services.de:public/lx-office-erp.git \
- --prefix=kivitendo-erp-3.0.0/ release-3.0.0 | gzip \
- > kivitendo-erp-3.0.0.tgz
-
- (der trailing slash bei prefix ist wichtig)
-
-* Tarball testen, wird das richtig entpackt?
-
-* SHA1 und MD5 von tarball machen und in *.sha1 bzw. *.md5 speichern
-
-* Alles auf Sourceforge hochladen
-
-* 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:
- kivitendo.de: deutsch, prosa, formell
- - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net)
- Mailinglisten: deutsch, freitext, informell
* Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
3. POST RELEASE
===============
-* Im Trac 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