FirmwareEntwicklung: Unterschied zwischen den Versionen

Aus Freifunk Franken
Wechseln zu:Navigation, Suche
(Init)
 
Keine Bearbeitungszusammenfassung
 
(45 dazwischenliegende Versionen von 10 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
* git clone https://github.com/FreifunkFranken/firmware.git
= Entwicklung =
* cd firmware
Siehe [https://git.freifunk-franken.de/freifunk-franken/firmware/src/branch/master/README.md README.md] im Firmware-Repository.


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.
= Weitere Informationen =
Auf der Mailingliste franken-dev@freifunk.net kannst du natürlich jederzeit Fragen stellen, falls etwas nicht klar sein sollte.


* ./buildscript selectcommunity community/franken.cfg
== 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.


Je nach dem, für welche Hardware die Firmware gebaut werden soll muss das BSP gewählt werden:
=== Begründung ===
* ./buildscript selectbsp bsp/board wr1043nd.bsp
Wir haben leider nicht die Men-Power um immer sicherzustellen, dass die Kompatibilität nach einem Release noch oder eben nicht mehr vorhanden ist.
* ./buildscript
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]<br>
Alpha: YYYYMMDD-alpha <br>
Beta: YYYYMMDD-beta <br>
Release: YYYYMMDD<br>
 
=== 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]<br>
Alpha: YYYYMMDD.[1-n]-alpha<br>
Beta: YYYYMMDD.[1-n]-beta <br>
Release: YYYYMMDD.[1-n] <br>
 
=== 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<br>
20160130-beta<br>
20160130.1-beta<br>
20160130.1<br>
 
Das nächste Beispiel geht davon aus, dass es auf dem selben Commit eine Alpha, Beta und Stable gibt:
 
20160130-alpha<br>
20160130-beta<br>
20160130<br>
 
 
== Ehemalige Tools ==
<div class="toccolours mw-collapsible mw-collapsed" style="overflow: auto">
=== Patchwork ===
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]]

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