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.
-== Prerequisites ==
+= Weitere Informationen =
-* apt-get install zlib1g-dev
+Auf der Mailingliste franken-dev@freifunk.net kannst du natürlich jederzeit Fragen stellen, falls etwas nicht klar sein sollte.
-* Sicherlich müssen noch mehr Abhängigkeiten Installiert werden, diese Liste wird sich hoffentlich nach und nach Füllen. Ein erster Ansatzpunkt sind die Abhängigkeiten von OpenWRT selbst
-* git clone https://github.com/FreifunkFranken/firmware.git
-* cd firmware
-== Erste Schritte ==
+== 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.
-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.
+=== 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.
-* ./buildscript selectcommunity community/franken.cfg
+=== 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:
-Je nach dem, für welche Hardware die Firmware gebaut werden soll muss das BSP gewählt werden:
+Build ohne release Tag: YYYYMMDD-[Anzahl commits seit vorherigem Release]-[Commit-ID]<br>
-* ./buildscript selectbsp bsp/board wr1043nd.bsp
+Alpha: YYYYMMDD-alpha <br>
-* ./buildscript
+Beta: YYYYMMDD-beta <br>
+Release: YYYYMMDD<br>
-= Was ist ein BSP? =
+=== Sonderfall ===
-Ein BSP beschreibt, was zu tun ist, damit ein Firmware Image für eine spezielle Hardware gebaut werden kann.
+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:
-Typischerweise ist eine folgene Ordner-Struktur vorhanden:
+Build ohne release Tag: YYYYMMDD.[1-n]-[Anzahl commits seit vorherigem Release]-[Commit-ID]<br>
-* .config
+Alpha: YYYYMMDD.[1-n]-alpha<br>
-* root_file_system/
+Beta: YYYYMMDD.[1-n]-beta <br>
-** etc/
+Release: YYYYMMDD.[1-n] <br>
-*** 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.
+=== 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.
-= Der Verwendung des Buildscripts =
+20160130-alpha<br>
-* Das BSP file durch das Buildscript automatisch als dot-Script geladen, somit stehen dort alle Funktionen zur Verfügung.
+20160130-beta<br>
-* Das Buildscript lädt ebenfalls automatisch das Community file und generiert ein dynamisches sed-Script, dies geschieht, damit die Templates mit den richtigen Werten gefüllt werden können.
+20160130.1-beta<br>
+20160130.1<br>
-== ./buildscript prepare ==
+Das nächste Beispiel geht davon aus, dass es auf dem selben Commit eine Alpha, Beta und Stable gibt:
-* Sourcen werden in einen separaten src-Folder geladen, sofern diese noch schont da sind. Zu den Sourcen zählen folgende Komponenten:
-** OpenWRT
-** Sämtliche Packages (ggfs werden Patches angewandt)
-* 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 ==
+20160130-alpha<br>
-* prebuild
+20160130-beta<br>
-** $target/files aufräumen
+20160130<br>
-*** (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 ==
-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.
-* prebuild
+== Ehemalige Tools ==
-* OpenWRT: make menuconfig ; make kernel_menuconfig
+<div class="toccolours mw-collapsible mw-collapsed" style="overflow: auto">
-* Speichern, y/n?
+=== Patchwork ===
-* Config-Format vereinfachen
+https://pw.freifunk-franken.de
-* Config ins BSP zurück speichern
+==== 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