[Freifunk Franken] Protokoll Techniktreffen 06.02.2016

[Christian Dresel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Guten Abend

Am 07.02.2016 um 14:46 schrieb delphiN:
> Am 06.02.2016 22:05, schrieb Tim Niemeyer:
>> Das ganze müsste mit dem Tag gelöst sein, denn am Tag kann ja 
>> unmittelbar abgelesen werden was drin ist und was nicht.
> 
> Wenn ich das richtig verstanden habe besteht die Version in
> Zukunft dann also immer aus Zeitstempel und Git-Tag? Also z.B. so 
> "20160207-g68314ea"? Das wäre natürlich eindeutig und damit ok.
> Nur Datum alleine geht meiner Meinung nach aber nicht.

ich glaube angedacht war eher:

    YYYYMMDD-[Anzahl commits]-[Commit-ID]
    YYYYMMDD-alpha
    YYYYMMDD-beta
    YYYYMMDD

alpha und beta ist klar, bin mir jetzt nur nicht sicher wie wir das
mit dem Final besprochen hatten. 1. oder letzter Punkt?

> 
> Falls der unwahrscheinliche Fall eintritt und ein einem Datum
> mehrere Releses gemacht werden müssen (z.B. weil beim ersten
> Release irgend etwas ganz schief gelaufen ist oder spät Abends noch
> ein wichtiges Update kam) dann wird es halt für den Benutzer
> schwierig auseinanderzuhalten welches jetzt die aktuellere Version
> ist. Zu erwarten, dass Benutzer in das Git-Log schauen ist mMn
> unrealistisch.

geb ich dir recht, aber ich glaube nicht das dies passieren wird. Wir
haben uns (sofern ich mich recht erinnere) dazu entschlossen das als
Datum das letzte Patch das eingeschlossen ist verwenden. Also wenn
heute release kommt und das letzte Patch aber von vorgestern ist,
kommt der Datum von vorgestern rein. Jetzt stellen wir nach dem
Release fest, da ist was kaputt, patchen es und releasen erneut, würde
ja der heutige Datum drinnen landen. Ich denke mit etwas gesunden
Menschenverstand und Aufmerksamkeit bekommt man das schon hin.

> 
> Außerdem wird man anhand des Datums nicht erkennen können ob es
> sich um ein reines Bugfix-Release oder um ein Major-Release
> handelt, dass evtl. sogar inkompatiebel zu alten Versionen ist.

da war unser Hauptproblem bei MAJOR.MINOR.PATCH. Wann ist denn etwas
inkompatibel damit MAJOR um 1 hoch geht? Geändertes Batman (Meshen
geht nicht mehr)? Geänderter VPN (meshen geht noch aber VPN nicht
mehr, als Meshrouter weiterhin nutzbar)? kein Netmon mehr?
Routermodell XY wird aufgrund mangelnder Leistung nicht mehr
untersützt? Es sind immer einzelne Funktionen hier inkompatibel aber
dennoch irgendwo kompatibel. Das ist alles irgendwie nicht ganz leicht
zu definieren. Das war (so wie ich es verstanden habe) der Hauptgrund
der Änderung.

> Hätte man diese Information z.B. in der Versions-Nummer könnte
> z.B. ein autoupdater (irgendwann mal) anhand der Versionummer
> entscheiden ob automatisch upgedated wird oder nicht. Patches
> könnten dann z.B. sofort eingespielt werden, major-releases nur
> manuell.

Autoupdater wird es nicht geben, angedacht war im WebUI ein Fenster
"hey du User da vorm Monitor am Server gibts ne neue Version update
doch mal - hier klicken für Update oder manuell hier herunterladen -
Patchnote findet sich hier".
Erkennen kann man es ganz leicht, man prüft ob die Version am Router
unterschiedlich zu der am Server ist. Da am Server immer die neuste
liegt, ist bei Unterschied eine neue Version drausen und das
Updatefenster kommt zum Vorschein. Angedacht war dazu eine Version
Datei im Firmwareroot wo die Version drinnen steht (ist am wenigstens
zum downloaden und besser als ein ganzes Dic-Listening zu scannen)

> 
> Man sollte sich vielleicht nochmal kurz die Zeit nehmen und
> komplett zu Ende diskutieren ob es wirklich sinnvoll ist ein
> anderes Versionierungs-Schema zu verwenden als alle mit bekannten
> Packet-Manager.

das haben wir eigentlich gemacht und ich habs jetzt auch begründet
warum, ich hoffe ich habs etwa so rüber gebracht wie beim treffen
besprochen wenn nicht lass ich mich gerne korrigieren. Auch hör ich
mir gerne deine Meinung dazu an.

mfg

Christian

> 
> Das wollte ich nur zu bedenken geben. Nicht, dass wir die 
> Versionierung dann in ein paar Monaten wieder komplett anpassen
> müssen. MAJOR.MINOR.PATCH-ZUSATZ oder etwas ähnliches erscheint mir
> immer noch der bessere Ansatz zu sein (rein sachlich
> argumentiert).
> 
> Gruß, delphiN
> 
> _______________________________________________ franken mailing
> list franken at freifunk.net 
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> 

- -- 
Kontaktmöglichkeiten ChristianD (Christian Dresel):
Jabber: ChristianD at jabber.community
E-Mail: fff at chrisi01.de
Facebook: https://www.facebook.com/christian.chili
Handy/Whatsapp & Festnetz: auf Nachfrage
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWt7IrAAoJEOID5jPgWNLiRLUQAKwd+Xtpl1y93FrMdDVTYSqS
vi/AjQ6z0sDMp0P+ODFk63VwD0hf47JlAVhzc0zznzr63kpeWBy04lGn3g/6QEAa
Y3pSZK59fK1nFp1k65/WFY5R09VN6SwiT7kKA7eAbRaBuAHuCnqbspttoxyxPiOI
63nSt62QaOV+fu1cBFGmSpIz/c0Zfd5xa9hWQOUl9adHb8Y9K7jMWhQBWLTWTxDW
86AgpV8fJC59Ah89DP8+AJaAY5XRHXqnwETj5tmn+BUDWeri9H+J8rYwcM6YCZcX
WqBeCXpuSgzDAz8gPRJ2SlUaMOckNSdYxXO/CNyeEmaKh2miLFpUqRXZrZh6OWQC
jFtFunWJsy73DN59jCBnOmkz1tgalijm8CYfnTGSb8gOA1SSOZ1hnIMuGhrJLPOa
JFZ4tSwLkOURAqow+8o1vUaXJxyzn1d8nHkjskdsi+KvZKs2mM/qWUgAFCIbR4r0
1QKUo8cAGB7S6ovvOMrtKbVJkjIeULhxvb2vxmY0TLWrae7U/5cd1VoM6m32Ua5r
LEwUjFE1Ef5S71j+C78hjISGDwHoJfJxfHIANSF1XD7CYDxH80dEGhKdf+9ZtBHD
HbZivEB6dUwB6DZ5AYjsfyUPdW9kNAk6I1ukXA78j5NTMNPwCjcNDWRQIL5UiCLX
4BThp2pag04O4aPpF7Ax
=CIVx
-----END PGP SIGNATURE-----