Ein Build erzeugen ================== $Id$ Die folgenden Punkte beziehen sich auf den Checkout des zugehörigen trunk-Zweiges (branches//trunk)! 0. Als erstes muss ein Ticket für das Release der neuen Version angelegt werden. 1. Bevor es richtig losgeht, sollten das Changelog und die Release-Notizen bereits angelegt und überarbeitet sein. Diese liegen in src/_RELEASE/changelog-.txt bzw. src/_RELEASE/releasenotes-.txt. und können mit dem tool generate-changelog aus dem org repo auf eisler erzeugt werden. cd /src/packages ~/org/trunk/tools/jira/fli4l/generate-changelog 3.10.11 ../_RELEASE/changelog-3.10.11.txt Die Änderungen des Kernel-Basispakets sind in die Abschnitten der übrigen Varianten (nonfree, virt und virt-nonfree) zu kopieren. Die Umwandlung ins HTML-Format wird mithilfe von gosh --style html.gosh changelog-.txt > changelog-.html gosh --style html.gosh releasenotes-.txt > releasenotes-.html vorgenommen. Anschließend muss in den generierten HTML Dateien noch eine Angabe zum Zeichensatz ergänz werden. Innerhalb der Tags ist die Zeile einzufügen. Alle diese Dateien einchecken (bei den HTML-Dateien vorher "svn add " ausführen!) und via commit-trunk, commit-testing und commit-stable durch alle Zweige (trunk der nächsten Version, testing, stable) schieben. 2. Mit src/check-files.pl prüfen, ob alle Paketlisten korrekt sind. 3. src/_RELEASE/release*.conf und src/packages/doc/doc/common/tex/doc/common_doc.conf auf korrekte Paketlisten bzw. Versionen kontrollieren. 4. src/packages/base/version.txt auf die nächste Version setzen und einchecken. 5. Versionsnummern in den provides-Anweisungen der erweiterten Prüfskripte anpassen: cd /src/packages sed -i 's/\(provides .*version\) /\1 /' */check/*.ext Beispiel: cd ~/fli4l/branches/3.10/trunk/src/packages sed -i 's/\(provides .*version\) 3\.10\.0/\1 3.10.1/' */check/*.ext Auch diese Änderungen mittels commit-trunk, commit-testing und commit-stable durch alle Zweige (trunk der nächsten Version, testing und stable) mergen. 6. Pakete mit dem entsprechenden Job im Jenkins "fli4l/release/stable_release_3-10-x" bauen, und prüfen dass der Prozess fehlerfrei durchgelaufen ist: Die Erzeugten Archive befinden sich auf dem Server "hangar" im direcory "/data/htdocs/fli4l/tarballs-distrib/" 7. Tag-Zweig auf Grundlage des stable-Zweiges erstellen: svn copy https://repo.nettworks.org/svn/fli4l/branches//stable \ https://repo.nettworks.org/svn/fli4l/tags/fli4l- wobei auch hier die "." in durch "_" ersetzt werden. Als Commit-Meldung bitte FFL-: fli4l released verwenden, wobei die für das Release von fli4l- vorgesehene Ticket-Nummer ist. 8. Die Liste der Treiber für unterstützte Netzwerkkarten im Wiki ist zu aktualisieren. Die Übersicht ist zu finden unter: https://ssl.nettworks.org/wiki/display/f/Netzwerkkarten Die letzte veröffentlichte Version ist durch die aktuelle zu ersetzen. Die Listen der Treiber lassen sich wie folgt generieren: $ cd src/packages/base/doc/deutsch/tex/base $ for t in lan wlan; do for a in x86 x86_64; do export ARCH=$a; if [ -f niclist_$t.csv ]; then rm niclist_$t.csv; fi; make niclist_$t.csv; ../../../common/tex/base/convert_csv2html.sh niclist_$t.csv > \ niclist_$t-$a.html; done; done Die generierten HTML Dateien sind in die entsprechenden Abschnitte im Wiki zu übertragen. 9. Danach erfolgt die Aktualisierung der Programmversionen. Die Liste findet sich im Wiki unter: https://web.nettworks.org/wiki/display/f/Programmversionen Die Versionen lassen sich mittels FBR und dem Befehl $ ./fbr-make show-versions ermitteln. Der Output muss für das Wiki entsprechend angepasst werden. Als Format eignet sich: "||Programmpaket||Version||" "|acpid|2.0.22|" Weiterhin sind Zeile mit "undefined" oder "virtual" als Version zu entfernen. Die so erstellte Tabelle kann mittels "Insert" -> "Markup (Confluence Wiki)" im Wiki eingefügt werden. 10. Das Changelog ist im Wiki zu veröffentlichen. Idealerweise kopiert man jeweils das letzte vorhandene Dokument und ändert anschließend Inhalt und Titel. Die Changelogs finden sich unter: https://web.nettworks.org/wiki/display/f/Changelogs Die folgenden Punkte beziehen sich auf die Archive, die via Jenkins-Job gebaut wurden, und die Release-Notes: 10. Release-Notes und Downloadverzeichnis an das Webteam mailen (org-website). 11. Release-Notes in ML bekanntgeben 12. Channeltopic in #fli4l ändern 13. Nach einem halben Tag (~12 Stunden) Release in NG bekanntgeben 14. Heise.de über das Release in Kenntnis setzen (bei stable-releases). 15. Softpedia erzählen, dass es ein Update gibt (bei stable-releases). 16. Wikipedia (de, en, fr) aktualisieren. 17. http://www.openhub.net/p/fli4l updaten. 18. Twitter Update zwitschern (Account haben priority, LeSpocky & fl_0)