[Freifunk-Bonn] Firmware Release 0.9

[eGeist]

Am 12.06.2012 10:23, schrieb 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

Ich vermute, Daniel meinte das auch so. (Vom Grundsatz her)

X<1 = Major. Unsere derzeitige Bastel-/Erprobungsrelease (0.9)

1.Y = Normale Release (1.0)

Z = Patch (z.B. die IP-Tables Veränderung) Wäre demnach eigentlich 0.7.1
gewesen, statt 0.8

Oder sehe ich das verkehrt.

Gruß
eGeist

Y = Minor