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:

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 werden hier in regelmäßigen Abständen automatisiert Firmware-Images für einen nighly-Channel des Autoupdaters gebaut.

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>.