483
Bearbeitungen
Änderungen
Firmware/Versionierung (Quelltext anzeigen)
Version vom 16. August 2017, 15:29 Uhr
, 15:29, 16. Aug. 2017Die Seite wurde neu angelegt: „Kategorie:Firmware Auf dieser Wikiseite wird die Versionierung der Freifunk Nordwest Firmware beschrieben und wie diese in unseren Git-Repository mittels…“
[[Kategorie:Firmware]]
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:
* [https://git.nordwest.freifunk.net/ffnw/siteconf siteconf]
* [https://git.nordwest.freifunk.net/ffnw/packages 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 [https://lists.ffnw.de//pipermail/dev/2016-November/001653.html 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:
<nowiki><build-framework>-<community>-<YYYY><MM><DD>-<Hardware hersteller>-<Hardware>-<Revision>.bin</nowiki>
gluon-ffnw-20171223-tp-link-tl-mr3020-v1.bin
Ein Beispiel für eine testing version:
<nowiki><build-framework>-<community>-<YYYY><MM><DD>_testing-<Hardware hersteller>-<Hardware>-<Revision>.bin</nowiki>
gluon-ffnw-20171223_testing-tp-link-tl-mr3020-v1.bin
Ein Beispiel für eine nighly version:
<nowiki><build-framework>-<community>-<YYYY><MM><DD>-<Commit ID>-<Hardware hersteller>-<Hardware>-<Revision>.bin</nowiki>
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 [https://blog.nordwest.freifunk.net/2016/01/17/ehrenamtlicher-gitlab-ci-experte-gesucht/ automatisiert] Firmware-Images für einen ''[http://firmware.nordwest.freifunk.net/unstable 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 ''<nowiki><YYYY><MM></nowiki>'' ausgelagert. Aus diesem Branch werden in regelmäßigen Abständen [https://blog.nordwest.freifunk.net/2016/01/17/ehrenamtlicher-gitlab-ci-experte-gesucht/ automatisiert] Firmware-Images für den ''[http://firmware.nordwest.freifunk.net/testing 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 <nowiki><YYYY><MM><DD></nowiki> 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]].
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:
* [https://git.nordwest.freifunk.net/ffnw/siteconf siteconf]
* [https://git.nordwest.freifunk.net/ffnw/packages 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 [https://lists.ffnw.de//pipermail/dev/2016-November/001653.html 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:
<nowiki><build-framework>-<community>-<YYYY><MM><DD>-<Hardware hersteller>-<Hardware>-<Revision>.bin</nowiki>
gluon-ffnw-20171223-tp-link-tl-mr3020-v1.bin
Ein Beispiel für eine testing version:
<nowiki><build-framework>-<community>-<YYYY><MM><DD>_testing-<Hardware hersteller>-<Hardware>-<Revision>.bin</nowiki>
gluon-ffnw-20171223_testing-tp-link-tl-mr3020-v1.bin
Ein Beispiel für eine nighly version:
<nowiki><build-framework>-<community>-<YYYY><MM><DD>-<Commit ID>-<Hardware hersteller>-<Hardware>-<Revision>.bin</nowiki>
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 [https://blog.nordwest.freifunk.net/2016/01/17/ehrenamtlicher-gitlab-ci-experte-gesucht/ automatisiert] Firmware-Images für einen ''[http://firmware.nordwest.freifunk.net/unstable 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 ''<nowiki><YYYY><MM></nowiki>'' ausgelagert. Aus diesem Branch werden in regelmäßigen Abständen [https://blog.nordwest.freifunk.net/2016/01/17/ehrenamtlicher-gitlab-ci-experte-gesucht/ automatisiert] Firmware-Images für den ''[http://firmware.nordwest.freifunk.net/testing 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 <nowiki><YYYY><MM><DD></nowiki> 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]].