X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=doc%2Frelease_management.txt;h=533915f8a2b34d4ef94cab670a6198a39fe38b00;hb=a93f1e395694983593c65b35427a13d68e46d380;hp=df6ba341d1b62b7f3d8097c55aa37f74c78eca99;hpb=420cc628dce84d55be98be5f9987b13879c2010e;p=kivitendo-erp.git diff --git a/doc/release_management.txt b/doc/release_management.txt index df6ba341d..533915f8a 100644 --- a/doc/release_management.txt +++ b/doc/release_management.txt @@ -28,7 +28,7 @@ als freundliche Checkliste zum ausdrucken und erweitern. 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 + 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) @@ -46,9 +46,10 @@ als freundliche Checkliste zum ausdrucken und erweitern. * 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 @@ -66,26 +67,26 @@ als freundliche Checkliste zum ausdrucken und erweitern. Beispiel für semiautomatisches bearbeiten: o Letztes Releasedatum: git log --pretty=format:%cd | head -1 - o Alle Bugs seit dem mit der Buzilla advanced search suchen: - + Bugs changed - + Only bugs changed between 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 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 - Das gleiche für trac: - o Individuelle Abfrage - + geändert zwischen und - + 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, 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ö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. @@ -97,22 +98,22 @@ als freundliche Checkliste zum ausdrucken und erweitern. 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. @@ -127,7 +128,7 @@ als freundliche Checkliste zum ausdrucken und erweitern. 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. @@ -167,15 +168,23 @@ als freundliche Checkliste zum ausdrucken und erweitern. * 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- + - Der git tag ist "release-" + - Das DB Upgradescript ist "release_" + + 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 Ipgradescript ist "release_" + - Das DB Upgradescript ist "release_" -* 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 @@ -198,14 +207,14 @@ als freundliche Checkliste zum ausdrucken und erweitern. * Annotated tag erstellen und pushen - $ git tag -a release-2.6.1 - $ git push origin tags/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= \ - --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) @@ -219,9 +228,9 @@ als freundliche Checkliste zum ausdrucken und erweitern. * Releasemessages schreiben für folgende Ziele: - - lx-office.org: deutsch, prosa, formell + - kivitendo.de: deutsch, prosa, formell - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net) - - mailinglisten: deutsch, freitext, informell + - Mailinglisten: deutsch, freitext, informell * Alle Releasemessages von mindestens einer Person Korrektur lesen lassen @@ -231,6 +240,6 @@ als freundliche Checkliste zum ausdrucken und erweitern. 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