kivitendo/doc/release_management.txt @ 3f26a3a5
| 385ffe49 | Sven Schöling | 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.
|
||||
| 8f94be3d | Sven Schöling | * (TODO: Release Candidates Zeitplan).
|
||
| 385ffe49 | Sven Schöling | |||
1. KONSISTENZ DES PROGRAMMS
|
||||
===========================
|
||||
| 27cb9c6a | Sven Schöling | * Testlauf t/test.sh
|
||
| f5aac6db | Sven Schöling | - Im Moment sind 3 Fehler optimal (die sind noch nicht angegangen):
|
||
| 27cb9c6a | Sven Schöling | 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.
|
||||
| 5457d1d2 | Sven Schöling | TODO: Dokumentieren wie der Releasemanager sich so eine DB baut, die
|
||
| 27cb9c6a | Sven Schöling | 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.
|
||||
| 385ffe49 | Sven Schöling | * Freeze auf der Mailingliste ansagen.
|
||
- Featurefreeze für beta
|
||||
| 5457d1d2 | Sven Schöling | - 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)
|
||||
| 385ffe49 | Sven Schöling | |||
* Status Bugzilla
|
||||
- Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr
|
||||
| f5aac6db | Sven Schöling | 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.
|
||||
| 385ffe49 | Sven Schöling | - 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
|
||||
| 3965e474 | Sven Schöling | aufgeführt sein.
|
||
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 copy&paste in eine Datei
|
||||
o perl -pale '$_=" - Bugfix $F[0]: @F[1..$#F]"' oder awk/sed drüber
|
||||
| f5aac6db | Sven Schöling | Das gleiche für trac:
|
||
o Individuelle Abfrage
|
||||
| 3a2fcef9 | Sven Schöling | + geändert zwischen <letztes Releasedatum> und <heute+1>
|
||
| f5aac6db | Sven Schöling | + Status closed
|
||
+ Lösung behobena
|
||||
+ Komponente ist Lx-Office ERP
|
||||
o Spalten: nur Zusammenfassung
|
||||
o sortieren nach Ticketnummer
|
||||
o rest weiter ab copy&paste
|
||||
| 3a2fcef9 | Sven Schöling | 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
|
||||
einen Tag mehr angeben.
|
||||
| 385ffe49 | Sven Schöling | - 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
|
||||
| ee2f4ec6 | Sven Schöling | 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:
|
||||
| 385ffe49 | Sven Schöling | |||
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
|
||||
| b5700901 | Sven Schöling | * Locales auf Vollständigkeit prüfen
|
||
$ scripts/locales.pl de
|
||||
| 385ffe49 | Sven Schöling | * SL::DB::Helper::ALL auf Vollständigkeit prüfen
|
||
| ec1daa3d | Sven Schöling | (TODO: Mag da einer ein Script für schreiben?
|
||
find SL/DB -type f | grep -v MetaSetup | grep -v Helper | grep -v Manager | sort
|
||||
hilft, kriegt aber die Sortierung durcheinander)
|
||||
| 385ffe49 | Sven Schöling | |||
* VERSION updaten
|
||||
| 1857ca9d | Sven Schöling | Zu den Versionierungen vor 3.0.0:
|
||
| 385ffe49 | Sven Schöling | |||
- 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>"
|
||||
| 1857ca9d | Sven Schöling | - Das DB Upgradescript ist "release_<snake_case_version>"
|
||
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>"
|
||||
| 385ffe49 | Sven Schöling | |||
| ec1daa3d | Sven Schöling | * Nur finales Release: Datenbankupgradescript "release_2_6_1" (mit aktueller
|
||
Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen.
|
||||
Leafscripte kriegt man mit
|
||||
| 385ffe49 | Sven Schöling | |||
$ scripts/dbupgrade2_tool.pl --nodeps
|
||||
| ec1daa3d | Sven Schöling | * Voraussichtliches Releasedatum im changelog eintragen
|
||
| 385ffe49 | Sven Schöling | |||
* Finaler Testlauf:
|
||||
t/test.sh
|
||||
| 27cb9c6a | Sven Schöling | Siehe oben für mögliche Ergebnisse.
|
||
| 385ffe49 | Sven Schöling | |||
* Alle Änderungen einchecken.
|
||||
2. RELEASE
|
||||
| 42d575b2 | Sven Schöling | ==========
|
||
| 385ffe49 | Sven Schöling | |||
* Annotated tag erstellen und pushen
|
||||
$ git tag -a release-2.6.1
|
||||
| e4422bec | Sven Schöling | $ git push origin tags/release-2.6.1
|
||
| 385ffe49 | Sven Schöling | |||
* 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
|
||||
| 42d575b2 | Sven Schöling | * Auf Sourceforge den Standarddownloadlink setzen
|
||
| 385ffe49 | Sven Schöling | * Releasemessages schreiben für folgende Ziele:
|
||
- lx-office.org: deutsch, prosa, formell
|
||||
| fe421d00 | Sven Schöling | - freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net)
|
||
| 385ffe49 | Sven Schöling | - mailinglisten: deutsch, freitext, informell
|
||
* Alle Releasemessages von mindestens einer Person Korrektur lesen lassen
|
||||
| fe421d00 | Sven Schöling | * Webseite aktualisieren, Releasemessages auf freecode und Mailinglisten posten
|
||
| 4f42c5f0 | Sven Schöling | |||
3. POST RELEASE
|
||||
| 42d575b2 | Sven Schöling | ===============
|
||
| 4f42c5f0 | Sven Schöling | |||
* Im Bugzilla die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können.
|
||||
| 42d575b2 | Sven Schöling | |||
* Nach einem Major Release alle Bugs die den Milestone hatten und nicht gefixt wurden zurücksetzen
|