[PATCH 3/4] added build command "release" to generate taged versions.

[Tim Niemeyer]

Hi

Am Freitag, den 29.01.2016, 00:10 +0100 schrieb delphiN:
> Hi,
> 
> Am 28.01.2016 08:55, schrieb Tim Niemeyer:
> > Ich verstehe die Intention hinter dem Patch nicht. Hier wäre eine
> > ausführliche commit message gut.
> 
> Ich versuch es mal vorsichtig zu erklären, was ich mir dabei gedacht
> hab. (Lieber etwas zu ausführlich als zu oberflächlich):
> 
> Mein Ziel war es (offensichtlich) in Zukunft builds mit der aktuellen
> Version im Dateinamen zu generieren (Patch 1/4). Meiner Meinung nach
> sollte man bei der Version zwischen einer Release-Nummer und einer
> Build-Id unterscheiden. Die Build-Id (z.B. "0.5.2-47-g4014228_dirty")
Ok, die Unterscheidung an sich ist sehr sinnvoll. Zumal vermutlich jeder
Build ein anderer wird. Trotzdem sollte sich die Basis (die Sourcen) des
Builds nicht ändern.

> ergibt sich aus dem aktuellen Source-Zustand und ist immer eindeutig
> pro commit. Solche Versionen werden standartmäßig z.B. wärend der
Richtig, "0.5.2-47-g4014228_dirty" beschreibt nicht den Build sondern
die Sourcen.

> Entwicklung generiert.
> Eine Release-Nummer ist eher etwas abstraktes, das man manuell während
> eines Release-Prozesses vergibt. Eine Release-Nummern setzen also
> einen Release-Prozess voraus.
> So wie ich das bisher verstanden habe besteht euer Prozess zur Zeit
> daraus, das der Tim ab und zu die letzte Stelle der Version hochzählt,
> ein Git-Tag vergibt, die Binaries auf den Dev-Server kopiert und eine
> Mail an die Listen schreibt mit den Änderungen.
In der Regel wird das Release lange vorher geplant und vorbereitet. In
enger Absprache wird kommuniziert was noch für das Release fehlt und
auch welche Version es werden soll. Bei der Versionsnummer gab es beim
letzten mal eine Verzögerung in der Kommunikation und da wir es eilig
hatten ist da dann leider was schief gegangen.

> Ein sehr unberechenbarer und spartanischer Release-Prozess aber
> funktioniert ja bisher ganz gut.
> 
> Das neue Kommando "buildscripte build release" sagt nur, dass statt
> der aktuellen Build-Id das letzte Release-Tags als Versionsnummer für
> den Dateinamen der Binaries verwendet werden soll. Wenn ich keinen
Es macht mMn nur Sinn, wenn man am Binary sieht was drin ist. Es hilft
nicht, wenn man sieht, okay das letzte Tag war x.y.z.

> Fehler gemacht habe enthält die Firmware trotzdem noch die
> vollständige Build-ID.
> 
> Das ganze hat den Vorteil, das eine Firmware zu einem definierte
> Zeitpunkt Released werden kann und der Dateiname dann auch "schön
> sauber" aussieht. Noch schöner wäre es natürlich, wenn bei "build
> release" automatisch das letzte Tag ausgecheckt und gebaut werden
> würde. So sollte man "build release" nur dann aufrufen, wenn man
> gerade ein neues Tag angelegt hat. Eine "Gefahr" seh ich hier jetzt
> aber nicht wirklich. Vor Allem wenn man bedenkt, das bisher immer alle
> Releases den gleichen Namen hatten!
Patch 1/4 ändert das ja bereits. Dieser Patch hingegen verschlechtert
meiner Meinung nach den Zustand, den Patch 1/4 eingeführt hat. Vor
diesem Patch steht im Dateinamen klar drin was da mal gebaut wurde. Mit
diesem Patch steht da plötzlich etwas drin, was gar nicht mehr zu den
Quellen passt. Hier entsteht eine Verwechselungsgefahr, dass ein
"x.y.z-230-g20a4cf8_dirty" als Build der Version "x.y.z" gehalten wird.
Im Vergleich zu ganz früher ist es ebenfalls eine Verschlechterung, da
man ganz früher gar nicht erst wusste was in dem Binary drin ist. Mit
diesem Patch könnte man sich fälschlicherweise auf den Dateinamen
verlassen.

> (Ich könnte mir auch vorstellen den Release-Prozess in das buildscript
> zu integrieren. Dann könnte z.B. der Befehl "buildscript release
> [patch*/minor/major]" automatisch einen neuen Tag vergeben, eine
> Release-Version bauen, die fertigen Dateien auf den Server kopieren
> und sogar eine Mail mit allen commits seit dem letzten Release versenden.
> Aber so weit wollte ich hier nicht gehen, deshab nur dieser kleine
> Schritt, gegen den aus meiner sicht nichts spricht.)
Ja, könnte man machen. Die Idee finde ich eigentlich sogar ganz gut, für
Projekte die viel Aufwand in die Releases stecken. Ich selbst würde da
jetzt allerdings erstmal kein großen Aufwand reinstecken, da wir aktuell
zu selten Releases bauen. Ich sehe auch nicht, dass wir da aktuell ein
striktes Release-Script benötigen. Ich denke das entwickelt sich von
selbst, wenn der Bedarf da ist.

> Klarer?
Ja, danke für die Aufklärung. Trotzdem kann ich den Patch leider nicht
unterstützen.

Tim

> delphiN
> 
> -- 
> franken-dev mailing list
> franken-dev at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160130/88b7ab75/attachment-0002.sig>