Firmware/Versionierung: Unterschied zwischen den Versionen
(Die 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…“) |
Tata (Diskussion | Beiträge) K (→Branches: Update URLs and to current state. URL in Stable-Branch still broken) |
||
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt) | |||
Zeile 5: | Zeile 5: | ||
== Repositories == | == Repositories == | ||
Diese Dokumentation gilt für die folgenden Repositories: | Diese Dokumentation gilt für die folgenden Repositories: | ||
− | * [https://git.nordwest.freifunk.net/ffnw/siteconf siteconf] | + | * [https://git.nordwest.freifunk.net/ffnw-firmware/siteconf siteconf] |
− | * [https://git.nordwest.freifunk.net/ffnw/packages packages] | + | * [https://git.nordwest.freifunk.net/ffnw-firmware/packages packages] |
== Allgemeines Versionsschema == | == Allgemeines Versionsschema == | ||
Zeile 42: | Zeile 42: | ||
== Branches == | == Branches == | ||
− | * '''Development-Branch:''' Die Entwicklung findet im Development-Branch mit dem namen ''master'' statt. ''Es | + | * '''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 ''[http://firmware.nordwest.freifunk.net/nightly 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 ''<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. | * '''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>''. | * '''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>''. | ||
Aktuelle Version vom 24. Oktober 2017, 16:42 Uhr
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>.
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.