[Freifunk-Bonn] Firmware Release 0.9

[Jan Lühr]

Hallo,

Am 11.06.2012 um 22:49 schrieb Daniel Meißner:

> Hallo Jan,
> 
> On Mon, 11 Jun 2012 22:35:24 +0200 Jan Lühr <ff at stephan.homeunix.net>
> wrote:
>> auf jenkins ist nun Release 0.9 verfügbar [1].
> […]
>> Weiterhin enthält die
>> Firmware nun eine Versions-Information im Banner und Dateinamen.
> 
> da sich die Versionsnummern in nächster Zeit noch
> stark überschlagen werden würde ich vorschlagen, die
> Versionierung Richtung Semantic Versioning (http://semver.org/) zu
> ändern.
> 
> Wie ist deine Meinung dazu?

Hmm .. ich finde den Artikel passt nicht wirklich.

"Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive."
und:
"Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes."

Ich sehe nicht so ganz, was die public API in unserem Fall sein soll, und welche Software von unserer Firmware abhängt.

Weiterhin:
"Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior."
"Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.( ...)"
"Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API."

Das wir schwierig anzuwenden, da wir hierzu eine Definition der Public API benötigen.  Eine Möglichkeit wäre, das Mesh-Protkoll als Public-API zu sehen, da es "nach außen strahlt" (passt nicht ganz, ein Mesh-Protokoll ist kein Application Programming interface)
Dann würden sich x und y direkt nach der batman-adv Version richten. (Das wäre aber reichlich sinnfrei, da die Zahlen die Zeit über konstant bleiben würden und eher die Versionsnummer verlängern)
Denkbar wäre auch, die ganze Netz-Konfiguration als Public-API zu verwenden, die ändert sich aber auch nicht wirklich häufiger (geine Änderung in 9 Releases  - und das ist schon ungewöhnlich häufig), s.d. wir auch hier eine eher lange, fixe Versionsnummer mit uns führen.

Mein aktueller Plan ist:
0.y für "Bastel-Releases". Release, bei denen noch konzeptionelle Probleme bestehen (hier konkret: Skalierbarkeit), die aber schon nutzbar sind.
X.Y, mit (X > 1), normale Releases, wobei zwei Firmware-Releases gemeinsam im gleichen Netz betrieben werden können.

Ich denke, das passt etwa zu Semantic-Versioning - ist das etwa das, was Du Dir vorstellst?

Alles Gute
Jan