Revision 385ffe49
Von Sven Schöling vor etwa 13 Jahren hinzugefügt
| doc/release_management.txt | ||
|---|---|---|
|
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: Reease Candidates Zeitplan).
|
||
|
|
||
|
|
||
|
|
||
|
1. KONSISTENZ DES PROGRAMMS
|
||
|
===========================
|
||
|
|
||
|
* Freeze auf der Mailingliste ansagen.
|
||
|
|
||
|
- Featurefreeze für beta
|
||
|
- Commitfreeze für finales Release
|
||
|
|
||
|
* Status Bugzilla
|
||
|
|
||
|
- Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr
|
||
|
offen sein.
|
||
|
- 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. (TODO ist mit ein bisschen SQL Magie direkt aus der
|
||
|
Bugzilla Datenbank holbar, diese Magie hier möglichst dokumentieren).
|
||
|
- Ausserdem einmal durch das git scrollen und sinnvolle grössere Ä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()", require "" etc an, und
|
||
|
sucht nach Abhängigkeiten dadrin. 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?
|
||
|
- 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.
|
||
|
|
||
|
4. Das Modul in der Installationsanleitung 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/Lx-Office-Dokumentation.pdf erstellen
|
||
|
(TODO: commands)
|
||
|
|
||
|
* 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 --user=<login> -n --all
|
||
|
|
||
|
# listet die entsprechenden Diffs:
|
||
|
$ scripts/rose_auto_create_model.pl --user=<login> --diff -n --all
|
||
|
|
||
|
* SL::DB::Helper::ALL auf Vollständigkeit prüfen
|
||
|
|
||
|
(TODO: Mag da einer ein Script für schreiben?)
|
||
|
|
||
|
* VERSION updaten
|
||
|
|
||
|
Zu den Versionierungen:
|
||
|
|
||
|
- 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>"
|
||
|
|
||
|
* Datenbankupgradescript "release_2_6_1" (mit aktueller Releasenummer)
|
||
|
erstellen und alle Leafscripte als Abhängigkeit einsetzen. Leafscripte
|
||
|
kriegt man mit
|
||
|
|
||
|
$ scripts/dbupgrade2_tool.pl --nodeps
|
||
|
|
||
|
* Voraussichtliches finales Releasedatum im changelog eintragen
|
||
|
|
||
|
* Finaler Testlauf:
|
||
|
|
||
|
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)
|
||
|
|
||
|
* 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
|
||
|
|
||
|
* 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
|
||
|
|
||
|
(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
|
||
|
|
||
|
* 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
|
||
|
|
||
|
* Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
|
||
|
|
||
|
* Webseite aktualisieren, Releasemessages auf freshmeat und Mailinglisten posten
|
||
Auch abrufbar als: Unified diff
release management doku