1. KONSISTENZ DES PROGRAMMS
===========================
+* Testlauf t/test.sh
+
+ - 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
+ - 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.
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
- - Ausserdem einmal durch das git scrollen und sinnvolle grössere Änderungen
+ Achtung: Trac hat im Moment noch Probleme, sodass 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.
$ 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
+ - zuindest 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.
Version bis zum erfolgreichen Login der neuen Version zu kriegen.
- Bekannte Probleme die im testing auftraten dokumentieren.
-* doc/Lx-Office-Dokumentation.pdf erstellen
+* doc/kivitendo-Dokumentation.pdf erstellen
(TODO: commands)
* scripts/rose_auto_create_model.pl update machen.
* Locales auf Vollständigkeit prüfen
$ scripts/locales.pl de
- $ scripts/locales.pl de_DE
* SL::DB::Helper::ALL auf Vollständigkeit prüfen
* 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-<version>
+ - Der git tag ist "release-<version>"
+ - Das DB Upgradescript ist "release_<snake_case_version>"
+
+ 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 Ipgradescript ist "release_<snake_case_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
t/test.sh
- - 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
+==========
* Annotated tag erstellen und pushen
- $ git tag -a release-2.6.1
- $ git push origin tgs/release-2.6.1
+ $ git tag -a release-3.0.0
+ $ git push origin tags/release-3.0.0
* Tarball erstellen
- $ 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
+ $ 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)
* Alles auf Sourceforge hochladen
+* Auf Sourceforge den Standarddownloadlink setzen
+
* 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
+ - 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
-* Webseite aktualisieren, Releasemessages auf freshmeat und Mailinglisten posten
+* 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.
-* Im Bugzilla 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
projects / kivitendo-erp.git / blobdiff