Firmware/Versionierung

Auf dieser Wikiseite wird die Versionierung der Freifunk Nordwest Firmware beschrieben und wie diese in unseren Git-Repository mittels Branches und Tags umgesetzt wird.

Repositories

Diese Dokumentation gilt für die folgenden Repositories:

• siteconf
• packages

Allgemeines Versionsschema

Am 30.11.2016 wurde auf der Dev Mailingliste ein neues Versionsschema besprochen, um einen Rolling release besser gerecht zu werden. Der thread ist hier zu finden DEV Firmware Versions Nummern ab 01.01.2017.

Entschieden wurde sich für Folgendes Versionsschema:

• Für alle Firmwareversionen != nighly und != testing soll gellten:

 YYYYMMDD

• Für testing soll gelten:

 YYYYMMDD_testing

• Für nighly als Sonderfall soll gelten:

 YYYYMMDD-Commit-ID

Ein Beispiel für eine nicht nighly oder testing version:

 <build-framework>-<community>-<YYYY><MM><DD>-<Hardware hersteller>-<Hardware>-<Revision>.bin

gluon-ffnw-20171223-tp-link-tl-mr3020-v1.bin

Ein Beispiel für eine testing version:

 <build-framework>-<community>-<YYYY><MM><DD>_testing-<Hardware hersteller>-<Hardware>-<Revision>.bin

gluon-ffnw-20171223_testing-tp-link-tl-mr3020-v1.bin

Ein Beispiel für eine nighly version:

 <build-framework>-<community>-<YYYY><MM><DD>-<Commit ID>-<Hardware hersteller>-<Hardware>-<Revision>.bin

gluon-ffnw-20171223-a51f4e9-tp-link-tl-mr3020-v1.bin

Bei Sysupgrade Images ist jeweils das tag sysubgrade vor ".bin" angehängt.

Branches

• Development-Branch: Die Entwicklung findet im Development-Branch mit dem namen master statt. Es wäre möglich hier in regelmäßigen Abständen automatisiert Firmware-Images für einen nighly-Channel des Autoupdaters zu bauen.
• Stable-Branch: Ist die Entwicklung einer Mayor-Version weit genug Fortgeschritten, wird die Entwicklung in einen eigenen Stable-Branch mit dem Namen <YYYY><MM> ausgelagert. Aus diesem Branch werden in regelmäßigen Abständen automatisiert Firmware-Images für den testing-Channel des Autoupdaters gebaut. Außerdem werden aus diesem Branch zu bestimmten Zeitpunkten manuell fertige Versionen erstellt, die mit einem Tag versehen werden.
• Feature-Branch: Soll ein neues Feature außerhalb des üblichen Releaseplans entwickelt werden weil es z.B. experimentell ist, wird dieses Feature in einem eigenen Feature-Branch erstellt. Die Benennung des Branches läuft nach dem Schema <namedesfeatures>.

Tags

Tags markieren fertige Firmware-Versionen und werden nach dem Schema <YYYY><MM><DD> benannt. Eine getaggte Firmware-Version wird immer aus einem Stable-Branch erstellt und über den Stable-Channel des Autoupdaters verteilt.

Siehe dazu auch Firmware/Releaseprozess.