Revision 6c604713
Von Moritz Bunkus vor etwa 12 Jahren hinzugefügt
| doc/release_management.txt | ||
|---|---|---|
| 49 | 49 |
- Commitfreeze für finales Release (Erfahrungswerte: 1 Tag für die erste |
| 50 | 50 |
Beta, 2-4h für jedes weitere Release, 1 Tag fürs finale Release) |
| 51 | 51 |
|
| 52 |
* Status Bugzilla
|
|
| 52 |
* Status Trac
|
|
| 53 | 53 |
|
| 54 | 54 |
- Aus dem Bugsprint sollten keine Bugs mit Target der neuen Version mehr |
| 55 | 55 |
offen sein, ist aber unrealistisch. Die noch offenen Bugs müssen bewertet |
| ... | ... | |
| 67 | 67 |
Beispiel für semiautomatisches bearbeiten: |
| 68 | 68 |
|
| 69 | 69 |
o Letztes Releasedatum: git log --pretty=format:%cd <release-tag> | head -1 |
| 70 |
o Alle Bugs seit dem mit der Buzilla advanced search suchen: |
|
| 71 |
+ Bugs changed |
|
| 72 |
+ Only bugs changed between <letztes Releasedatum> and Now |
|
| 73 |
+ where only one or more of the following changed: "Resolution" |
|
| 74 |
+ and the new value was: "FIXED" |
|
| 75 |
o columns ändern auf nur "Full Summary" |
|
| 70 |
o Alle Bugs seitdem mit Trac suchen ("Tickets anzeigen" ->
|
|
| 71 |
"Individuelle Abfrage"): |
|
| 72 |
+ Status: [X] closed |
|
| 73 |
+ Geändert: zwischen <letztes Releasedatum> und <heute> |
|
| 74 |
+ Lösung: [x] behoben [x] Duplikat [x] funktioniert-bei-mir |
|
| 75 |
+ Komponente: ist kivitendo ERP |
|
| 76 |
+ Spalten: [x] Zusammenfassung |
|
| 77 |
o sortieren nach Ticketnummer |
|
| 76 | 78 |
o copy&paste in eine Datei |
| 77 | 79 |
o perl -pale '$_=" - Bugfix $F[0]: @F[1..$#F]"' oder awk/sed drüber |
| 78 | 80 |
|
| 79 |
Das gleiche für trac: |
|
| 80 |
o Individuelle Abfrage |
|
| 81 |
+ geändert zwischen <letztes Releasedatum> und <heute+1> |
|
| 82 |
+ Status closed |
|
| 83 |
+ Lösung behobena |
|
| 84 |
+ Komponente ist Lx-Office ERP |
|
| 85 |
o Spalten: nur Zusammenfassung |
|
| 86 |
o sortieren nach Ticketnummer |
|
| 87 |
o rest weiter ab copy&paste |
|
| 88 |
|
|
| 89 |
Achtung: trac hat im Moment noch Probleme, so dass Bugs zum teil mit nicht |
|
| 81 |
Achtung: Trac hat im Moment noch Probleme, sodass Bugs zum Teil mit nicht |
|
| 90 | 82 |
existenten Lösungen geschlossen werden. Besser ist es, sich die Lösung als |
| 91 | 83 |
eigene Spalte anzeigen zu lassen, die Lösungen zu filtern, die nicht |
| 92 | 84 |
erwünscht sind, und den Rest zu formatieren (TODO: Script erweitern) |
| 93 | 85 |
|
| 94 |
Achtung: trac benutzt Datum 00:00:00 als obere Grenze, dass heisst, immer
|
|
| 86 |
Achtung: Trac benutzt Datum 00:00:00 als obere Grenze, dass heißt, immer
|
|
| 95 | 87 |
einen Tag mehr angeben. |
| 96 | 88 |
|
| 97 |
- Ausserdem einmal durch das git scrollen und sinnvolle grössere Änderungen
|
|
| 89 |
- Ausserdem einmal durch das git scrollen und sinnvolle größere Änderungen
|
|
| 98 | 90 |
ins changelog übertragen. Muss nur einmal gemacht werden, möglichst danach |
| 99 | 91 |
nur noch inkrementell. |
| 100 | 92 |
|
| ... | ... | |
| 106 | 98 |
sucht nach Abhängigkeiten dadrin. Achtung: require wird im Moment nicht |
| 107 | 99 |
erkannt. Die Farbcodes bedeuten: |
| 108 | 100 |
|
| 109 |
grün: Alles gut, das Modul ist entweder seit Ewigkeiten im perl core, oder
|
|
| 101 |
grün: Alles gut, das Modul ist entweder seit Ewigkeiten im Perl core, oder
|
|
| 110 | 102 |
ist in modules/* dabei. |
| 111 |
gelb: Das Modul ist nach 5.8.0 in den core gekommen, oder steht ordnungsgemäß
|
|
| 103 |
gelb: Das Modul ist nach 5.8.0 in den Core gekommen, oder steht ordnungsgemäß
|
|
| 112 | 104 |
im InstallationCheck.pm |
| 113 |
rot: Noch nie gesehen das Modul. muss eingepflegt werden.
|
|
| 105 |
rot: Noch nie gesehen das Modul. Muss eingepflegt werden.
|
|
| 114 | 106 |
|
| 115 | 107 |
Sollte es nicht dokumentierte Abhängigkeiten geben, muss Folgendes gemacht |
| 116 | 108 |
werden: |
| 117 | 109 |
|
| 118 | 110 |
1. Wo kriegt man das Modul her? |
| 119 |
- debian paket?
|
|
| 120 |
- cpan paket?
|
|
| 121 |
- cpan devel version?
|
|
| 111 |
- Debian-Paket?
|
|
| 112 |
- CPAN-Paket?
|
|
| 113 |
- CPAN-Devel-Version?
|
|
| 122 | 114 |
|
| 123 | 115 |
2. Welche Mindestversion funktioniert sicher? |
| 124 |
- zuindest deine aktuelle. ansonsten auch mal im cpan changelog schauen wie
|
|
| 116 |
- zuindest deine aktuelle. ansonsten auch mal im CPAN changelog schauen, wie
|
|
| 125 | 117 |
alt die ist, und was alles dazugekommen ist. |
| 126 | 118 |
|
| 127 | 119 |
3. Das Modul in SL/InstallationCheck.pm eintragen. Testen. |
| ... | ... | |
| 136 | 128 |
Version bis zum erfolgreichen Login der neuen Version zu kriegen. |
| 137 | 129 |
- Bekannte Probleme die im testing auftraten dokumentieren. |
| 138 | 130 |
|
| 139 |
* doc/Lx-Office-Dokumentation.pdf erstellen
|
|
| 131 |
* doc/kivitendo-Dokumentation.pdf erstellen
|
|
| 140 | 132 |
(TODO: commands) |
| 141 | 133 |
|
| 142 | 134 |
* scripts/rose_auto_create_model.pl update machen. |
| ... | ... | |
| 176 | 168 |
|
| 177 | 169 |
* VERSION updaten |
| 178 | 170 |
|
| 179 |
Zu den Versionierungen vor 3.0.0: |
|
| 180 |
|
|
| 181 |
- Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen) |
|
| 182 |
- Das Paket heißt lx-office-erp (klein, plus "-erp") |
|
| 183 |
- Der Standardpfad ist lxoffice-erp-<version> (fehlender Bindestrich) |
|
| 184 |
- Der git tag ist "release-<version>" |
|
| 185 |
- Das DB Upgradescript ist "release_<snake_case_version>" |
|
| 186 |
|
|
| 187 | 171 |
Zu den Versionierungen ab 3.0.0: |
| 188 | 172 |
|
| 189 | 173 |
- Das Programm heißt kivitendo (alles klein) |
| ... | ... | |
| 192 | 176 |
- Der git tag ist "release-<version>" |
| 193 | 177 |
- Das DB Upgradescript ist "release_<snake_case_version>" |
| 194 | 178 |
|
| 195 |
* Nur finales Release: Datenbankupgradescript "release_2_6_1" (mit aktueller |
|
| 179 |
Zu den Versionierungen vor 3.0.0: |
|
| 180 |
|
|
| 181 |
- Das Programm heißt Lx-Office (großes LO, mit Bindestrich dazwischen) |
|
| 182 |
- Das Paket heißt lx-office-erp (klein, plus "-erp") |
|
| 183 |
- Der Standardpfad ist lxoffice-erp-<version> (fehlender Bindestrich) |
|
| 184 |
- Der git tag ist "release-<version>" |
|
| 185 |
- Das DB Upgradescript ist "release_<snake_case_version>" |
|
| 186 |
|
|
| 187 |
* Nur finales Release: Datenbankupgradescript "release_3_0_0" (mit aktueller |
|
| 196 | 188 |
Releasenummer) erstellen und alle Leafscripte als Abhängigkeit einsetzen. |
| 197 | 189 |
Leafscripte kriegt man mit |
| 198 | 190 |
|
| ... | ... | |
| 236 | 228 |
|
| 237 | 229 |
* Releasemessages schreiben für folgende Ziele: |
| 238 | 230 |
|
| 239 |
- lx-office.org: deutsch, prosa, formell
|
|
| 231 |
- kivitendo.de: deutsch, prosa, formell
|
|
| 240 | 232 |
- freecode.com: englisch, max 600 zeichen, technische stichpunkte aus dem changelog (ehemals freshmeat.net) |
| 241 |
- mailinglisten: deutsch, freitext, informell
|
|
| 233 |
- Mailinglisten: deutsch, freitext, informell
|
|
| 242 | 234 |
|
| 243 | 235 |
* Alle Releasemessages von mindestens einer Person Korrektur lesen lassen |
| 244 | 236 |
|
| ... | ... | |
| 248 | 240 |
3. POST RELEASE |
| 249 | 241 |
=============== |
| 250 | 242 |
|
| 251 |
* Im Bugzilla die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können.
|
|
| 243 |
* Im Trac die aktuelle Version ergänzen, damit dafür Bugs eingespielt werden können.
|
|
| 252 | 244 |
|
| 253 | 245 |
* Nach einem Major Release alle Bugs die den Milestone hatten und nicht gefixt wurden zurücksetzen |
Auch abrufbar als: Unified diff
Aktualisierung Dokumentation zum Release-Management