Aktuelle Version vom 18. Februar 2023, 18:37 Uhr

Entwicklung

Siehe README.md im Firmware-Repository.

Weitere Informationen

Auf der Mailingliste franken-dev@freifunk.net kannst du natürlich jederzeit Fragen stellen, falls etwas nicht klar sein sollte.

Versionierung

Beim Techniktreffen vom 06.02.2016 wurde ein neues Versionierungsschema beschlossen. Am 10.02.2016 wurden noch einige Details geklärt.

Begründung

Wir haben leider nicht die Men-Power um immer sicherzustellen, dass die Kompatibilität nach einem Release noch oder eben nicht mehr vorhanden ist. Dadurch ist der Interpretationsspielraum bei regulären Versionsnummern sehr hoch. Um diesen Spielraum abzuschaffen, steigen wir auf das Datumsschema um.

Schema

Die Versionsnummer orientiert sich grundsätzlich am Commit-Datum des letzten Commits. Auf diesen Commit wird dann entsprechend das Git-Tag gesetzt. Daraus ergibt sich folgendes Schema:

Build ohne release Tag: YYYYMMDD-[Anzahl commits seit vorherigem Release]-[Commit-ID]
Alpha: YYYYMMDD-alpha
Beta: YYYYMMDD-beta
Release: YYYYMMDD

Sonderfall

Für den seltenen Fall, dass es mehrere Tags an einem Tag geben muss, wird der Präfix entsprechend angepasst. Daraus ergibt sich folgendes Schema:

Build ohne release Tag: YYYYMMDD.[1-n]-[Anzahl commits seit vorherigem Release]-[Commit-ID]
Alpha: YYYYMMDD.[1-n]-alpha
Beta: YYYYMMDD.[1-n]-beta
Release: YYYYMMDD.[1-n]

Beispiele

Folgendes Beispiel geht davon aus, dass es eine Alpha und eine Beta Version auf dem selben Commit gegeben hat. In der Beta wurde am selben Tag ein massives Problem festgestellt, deshalb gab es eine neue Beta. Diese basiert auf einem neueren Commit und wird später auch so released.

20160130-alpha
20160130-beta
20160130.1-beta
20160130.1

Das nächste Beispiel geht davon aus, dass es auf dem selben Commit eine Alpha, Beta und Stable gibt:

20160130-alpha
20160130-beta
20160130

Ehemalige Tools

Patchwork

https://pw.freifunk-franken.de

Patch aus dem Patchwork ins eigene Git laden

curl -s https://pw.freifunk-franken.de/patch/797/mbox/ | git am -

Die Zahl in der URL durch die Patchnummer ersetzen aus dem Patchwork

Mantis

https://mantis.freifunk-franken.de

@@ Zeile 1: / Zeile 1: @@
-= Benutzung des Buildscripts =
+= Entwicklung =
+Siehe [https://git.freifunk-franken.de/freifunk-franken/firmware/src/branch/master/README.md README.md] im Firmware-Repository.
-* git clone https://github.com/FreifunkFranken/firmware.git
+= Weitere Informationen =
-* cd firmware
+Auf der Mailingliste franken-dev@freifunk.net kannst du natürlich jederzeit Fragen stellen, falls etwas nicht klar sein sollte.
-Mit Hilfe der Community-Files werden Parameter, wie die ESSID, der Kanal sowie z.B. die Netmon-IP gesetzt. Diese Einstellungen sind Community weit einheitlich und müssen i.d.R. nicht geändert werden.
+== Versionierung ==
+Beim Techniktreffen vom [[Protokolle/20160206|06.02.2016]] wurde ein neues Versionierungsschema beschlossen. Am [[Protokolle/20160210|10.02.2016]] wurden noch einige Details geklärt.
-* ./buildscript selectcommunity community/franken.cfg
+=== Begründung ===
+Wir haben leider nicht die Men-Power um immer sicherzustellen, dass die Kompatibilität nach einem Release noch oder eben nicht mehr vorhanden ist.
+Dadurch ist der Interpretationsspielraum bei regulären Versionsnummern sehr hoch.
+Um diesen Spielraum abzuschaffen, steigen wir auf das Datumsschema um.
-Je nach dem, für welche Hardware die Firmware gebaut werden soll muss das BSP gewählt werden:
+=== Schema ===
-* ./buildscript selectbsp bsp/board wr1043nd.bsp
+Die Versionsnummer orientiert sich grundsätzlich am Commit-Datum des letzten Commits. Auf diesen Commit wird dann entsprechend das Git-Tag gesetzt.
-* ./buildscript
+Daraus ergibt sich folgendes Schema:
-= Was ist ein BSP? =
+Build ohne release Tag: YYYYMMDD-[Anzahl commits seit vorherigem Release]-[Commit-ID]<br>
-Ein BSP beschreibt, was zu tun ist, damit ein Firmware Image für eine spezielle Hardware gebaut werden kann.
+Alpha: YYYYMMDD-alpha <br>
+Beta: YYYYMMDD-beta <br>
+Release: YYYYMMDD<br>
-Typischerweise ist eine folgene Ordner-Struktur vorhanden:
+=== Sonderfall ===
-* .config
+Für den seltenen Fall, dass es mehrere Tags an einem Tag geben muss, wird der Präfix entsprechend angepasst. Daraus ergibt sich folgendes Schema:
-* root_file_system/
-** etc/
-*** rc.local.board
-*** config/
-**** board
-**** network
-**** system
-*** crontabs/
-**** root
-Die Daten des BSP werden nie alleine verwendet. Zu erst werden immer die Daten aus dem "default"-BSP zum Ziel kopiert, erst danach werden die Daten des eigentlichen BSPs dazu kopiert. Durch diesen Effekt kann ein BSP die "default" Daten überschreiben.
+Build ohne release Tag: YYYYMMDD.[1-n]-[Anzahl commits seit vorherigem Release]-[Commit-ID]<br>
+Alpha: YYYYMMDD.[1-n]-alpha<br>
+Beta: YYYYMMDD.[1-n]-beta <br>
+Release: YYYYMMDD.[1-n] <br>
-= Der innere Aufbau des Buildscripts =
+=== Beispiele ===
-* Das BSP file wird als dot Script eingeladen.
+Folgendes Beispiel geht davon aus, dass es eine Alpha und eine Beta Version auf dem selben Commit gegeben hat.
-* Community file generiert dynamisches sed-Script, dies geschriebt, damit die Templates mit den richtigen Werten gefüllt werden.
+In der Beta wurde am selben Tag ein massives Problem festgestellt, deshalb gab es eine neue Beta. Diese basiert auf einem neueren Commit und wird später auch so released.
-== ./buildscript prepare ==
+20160130-alpha<br>
-* Sourcen werden in einen separaten src-Folder geladen, sofern diese noch schont da sind. Zu den Sourcen zählen folgende Komponenten:
+20160130-beta<br>
-** OpenWRT
+20160130.1-beta<br>
-** Sämtliche Packages (ggfs werden Patches angewandt)
+20160130.1<br>
-* Ein ggfs altes Target wird gelöscht
-* OpenWRT wird ins Target exportiert (kopiert)
-* Eine OpenWRT Feed-Config wird mit dem lokalen Source Verzeichnis als Quelle angelegt
-* Die Feeds werden geladen
-* Spezielle Auswahl an Paketen wird geladen
-* Patches werden angewandt
-* board_prepare() aus dem BSP wird aufgerufen (wird. z.B. fur Patches für eine bestimmte HW verwendet)
-== ./buildscript build ==
+Das nächste Beispiel geht davon aus, dass es auf dem selben Commit eine Alpha, Beta und Stable gibt:
-* prebuild
-** $target/files aufräumen
-*** (In $target/files liegen Dateien, die später direkt im Ziel-Image landen)
-** Files aus default-bsp und bsp kopieren
-** OpenWRT- und Kernel-Config kopieren
-** board_prebuild() aus dem BSP wird aufgerufen
-* Templates transformieren
-* GIT Versionen speichern: $target/files/etc/firmware_release
-* OpenWRT: make
-* postbuild
-** board_postbuild() wird aufgerufen
-== ./buildscript config ==
+20160130-alpha<br>
-Um das Arbeiten mit den OpenWRT .config's zu vereinfachen bietet das Buildscript die Möglichkeit die OpenWRT menuconfig und die OpenWRT kernel_menuconfig aufzurufen. Im Anschluss hat man die Möglichkeit die frisch editierten Configs in das BSP zu übernehmen.
+20160130-beta<br>
+20160130<br>
-* prebuild
-* OpenWRT: make menuconfig ; make kernel_menuconfig
+== Ehemalige Tools ==
-* Speichern, y/n?
+<div class="toccolours mw-collapsible mw-collapsed" style="overflow: auto">
-* Config-Format vereinfachen
+=== Patchwork ===
-* Config ins BSP zurück speichern
+https://pw.freifunk-franken.de
+==== Patch aus dem Patchwork ins eigene Git laden ====
+<pre>
+curl -s https://pw.freifunk-franken.de/patch/797/mbox/ | git am -
+</pre>
+Die Zahl in der URL durch die Patchnummer ersetzen aus dem Patchwork
+=== Mantis ===
+https://mantis.freifunk-franken.de
+</div>
+[[Kategorie:Technik]]

FirmwareEntwicklung: Unterschied zwischen den Versionen