Nightly Versionen - was ist enthalten? Bedeutung der Versionsnummern

Kann mir jemand sagen, wie ich raus finde, welcher Source-Code einer bestimmten Version zu Grunde liegt? Ich habe bspw. am 30.09. bei mir Homegear installiert und zwar in der Version 0.8.0-3085. Wenn ich nun hier nachsehe: https://homegear.eu/downloads.html?version=0.8, dann steht dort als Build Date für die Raspbian Version 0.8.0-3085 der 02.10.2020 - wurde hier einfach der Code Stand der Revision 3085 nochmal neu gebaut, ohne dass etwas hinzugekommen ist oder wurde hier der Source Code verändert, ohne die Versionsnummer zu ändern?

Ich hatte nachdem einer der Entwickler netterweise auf meinen Hinweis hin hier kurzfristig einen Bug gefixt hat (Error: Physical interface with title "general" has no type or id set) auch schon eine direkte Anfrage an @sathya geschickt, aber leider noch keine Antwort bekommen, aber vielleicht kann das ja auch jemand anderes beantworten, denn ich würde gerne wissen, ob dieser Fix bspw. in der Version enthalten ist, allerdings ist mir nicht klar, wie ich das herausfinden kann.

Hey Roland :slight_smile:

Die Buildserver laufen quasi durch und kompilieren nach und nach die nightly für alle Plattformen. D.h. wenn die x86-Version am 30.9. kompiliert wurde, kann es sein, dass die raspbian armhf stretch Variante erst ein paar Tage später kompiliert wurde.

@sathya hat leider mom viel um die Ohren, nach seinem Urlaub. Ein Changelog wäre wünschenswert - oder schnellere Releases aus der nightly. Das hat Sathya auch schon gesagt.

Wenn ich mich recht erinnere, hängt die Revisions-Nummer ausschliesslich an der libhomegearbase, Änderungen an anderen Modulen sind nicht berücksichtigt.

Das ist aus meinem Hinterkopf und mag falsch sein, ist aber das woran ich mich erinnere. Also Vorsicht, keine sichere Aussage.

1 Like

Die Versionsnummer hängt an homegear und libhomegear-base.
Änderungen an anderen Modulen werden nicht in der Versionierung, sondern lediglich beim Anstoßen zum kompilieren berüchsichtigt. Das kann dann logischerweise dazu führen, dass obwohl die Versionsnummer dieselbe ist, aktuellste Änderungen an anderen Modulen nur in Kompilaten nach dem Änderungszeitpunkt enthalten sind.
Wenn nun also die Revision dieselbe ist, sich das Build-Datum aber geändert hat, spricht das für eine Änderund an einem Modul außer homegear und libhomeger-base oder für einen manuellen Anstoß des Builds.
Es gibt aktuell nicht wirklich eine komfortable Möglichkeit herauszufinden, was in welchem Build enthalten ist. Das steht aber auf der ToDo-Liste.

2 Likes

Danke schon mal für die Infos dazu soweit!

Vielleicht könnt ihr mir auch bei einer anderen Fragestellung zu einem verwandten Thema weiterhelfen: Ich habe Homegear auf Raspbian über das Repo installiert und nun eine 0.8.x Version installiert. Im Nachhinein war ich überrascht, als ich gelesen habe, dass 0.7.x die Stable ist. In den Repos für Debian Buster bspw. ist sind auch nur die 0.7er Versionen im offiziellen Repo, wieso sind beim Raspbian Repo die Nightly-Versionen mit im offiziellen Repo? Sollte das Verhalten ob ich eine stable oder testing/nightly bekomme nicht unabhängig von der eingesetzten Plattform sein?

Bitte nicht falsch verstehen: Ich will hier nicht als Neuling gleich rum meckern, ich finde es toll, dass es das Projekt gibt, ich möchte einfach nur die Zusammenhänge etwas besser verstehen, um nachvollziehen zu können, wie und wann denn bspw. ein Fix den jemand auf DEV gemacht hat nun in welche Version rein kommt.

Gruß Roland

2 Likes

Hi @rolandw,

da scheint sich tatsaechlich ein nightly in das stable-Repo “verirrt” zu haben.
Normalerweise ist (derzeit) 0.8.x das nightly Build, 0.7.x Stable bzw. Testing. Fuer die nightly Builds gibt es auch kein Repository, die Version kann nur ueber ein Install-Script installiert werden.

Warum jetzt ein nightly im stable liegt muesste @sathya einmal schauen :thinking:

– Micha

1 Like

@Micha
Kannst du generell mal ein paar Worte dazu sagen, wie so der Entwicklungsprozess ist - oder ggf. gerne auf eine Doku verweisen, wenn das irgendwo steht und ich es übersehen haben sollte:

  • wenn irgendwas angepasst oder gefixt wird, dann vermutlich auf dem entsprechenden dev Branch des Moduls, richtig?
  • wie und wann kommt es von dort auf testing oder master? arbeitet ihr mit Pull-Requests?
    • wann kommen generell Änderungen in welchen Branch?
  • wer baut Versionen und pushed sie in die Repos? Ist da ein CI-Server hinter oder ist das ein manueller Prozess?
  • wer zählt wann die Revision hoch, die in der Nightly verwendet wird?
    • wird das manuell oder automatisch gemacht?
  • welcher Branch entspricht welcher Version? master=stable, testing=nightly?

Mit neugierigen Grüßen
Roland :wink:

Hey @rolandw,

zu den Entwicklungsprozessen im Detail kann ich nur rudimentaer etwas sagen, ich bin kein “Core”-Entwickler … ich steuere nur die Admin-UI und ein paar kleinere Bugfixes bei :wink: Ich versuch mal so gut es geht deine Fragen zu beantworten, @sathya oder @Sim moegen mich bitte korrigieren :innocent:

Bugfixes bzw. neue Features werden zuerst im dev-Branch vorgenommen, das ist korrekt. Dieser dev-Branch wird dann nach einiger Zeit in testing gemerged, und testing wiederum in den master. Das findet in unregelmaessigen Abstaenden und manuell statt.

Die Builds der jeweiligen Branches werden automatisiert erstellt. Die Versionen werden manuell gesetzt, die Revisions meines Wissens nach automatisiert ueber die Commits.

Die unterschiedlichen Branches ergeben folgende Versionen:
dev = nightly (unstable, kann broken sein)
testing = testing (beta)
master = stable

– Micha

4 Likes