Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[SKB]

Grüß Euch,
weiß jemand, wie ioBroker mit den Versionen von Github umgeht?

Meine Frage zielt darauf ab, wie Zwischenversionen "gehandhabt" werden?!

Heisst: man hat einen Adapter nun mit Version 0.2.1 im offiziellen Repo.

Nun entwickelt man nach und nach Version 0.3.0-alpha.[...], 0.4.0-alpha.[...] und lädt sie zu Git hoch, bis man ggf. bei Version 0.4.1 dann zufrieden ist und diese wieder für das offizielle Repo (PR) anmeldet.

Woher kommt dann die Info, das ja in Version 0.4.1 alles drin ist, was zwischen 0.2.1 und 0.4.0-alpha[...] verändert wurde?

Oder, führt man das nochmals bei dem Platzhalter ### WORK IN PROGRESS an?

Danke Euch!

[mcm1957]

@skb
So ganz versteh ich deine Frage nicht.

Wenn du das Releasescript verwendest werden ALLE Versionen zunächst mal im README.md eingetragen,d.h. der WORK IN PROGRESS Marker wird durch die gewünschte Version ersetzt.

Der Inhalt des Changelogs kommt mit dieser Versionsnummer im io-package.json und wenn du die standardmässigen Workflows verwendest auf npmjs.

Alle normalen Versionen - also solche ohne .Alpha.x - erscheinen automatisch im Lates Repo.

Sobald du einen PR für Stable erstellst kommt die Release auch ins Stable Repo. Dabei wird an der Release nichts mehr verändert.

Prinzipiell sind daher alle Changes mit den Versionen in denen sie oassiert sind für Zser nachvollziehbar.

Was ist nun drin Problem? Es ist NICHT üblich die Releasenotes zu verschmelzen. (Ausgenommen ev bei alphas). Dies würde auch beta Tester im Latest Repo eher verwirrend. Der Stable User kann ja jederzeit alle changes zwischen seiner installierten Version und der neuen Version nachlesen. (Was aber 90% eh nicht tun )

Wenn du z.B.bei alphas zusammenziehen willst kannst du einfach das letzte alpha versionslabel durch WORK IN PROGRESS ersetzen und die neueren Changes dazu schreiben und das Releasescript neu starten.

[SKB]

@mcm1957 das heißt im Endeffekt lässt man die Versionen einfach so durchlaufen, wie man sie erstellt und irgendwann ist dann die letzte Major Version im stable und der User sieht dann auch die Alpha Versionen darunter in der Readme.

Man muss also nicht noch extra alle Änderung der Alpha/Beta bei der nächsten Major mitteilen. Das sieht man ja dann an Alphas darunter, korrekt?

[mcm1957]

@skb said in Wie am Besten mit den Versionen bei Github umgehen?:

@mcm1957 das heißt im Endeffekt lässt man die Versionen einfach so durchlaufen, wie man sie erstellt und irgendwann ist dann die letzte Major Version im stable und der User sieht dann auch die Alpha Versionen darunter in der Readme.

Man muss also nicht noch extra alle Änderung der Alpha/Beta bei der nächsten Major mitteilen. Das sieht man ja dann an Alphas darunter, korrekt?

Im Prinzip korrekt.
Bei patch / minor / major würd ichs jedenfalls so machen. Bei alphaskann man im README gern zusammenziehen da due ja nicht ins latest gehen (sollen) und nur im kleinsten Kreis getestet werden.

Wenn ein allgemeiner Test gewünschten ist gern normale Version erzeugen undvia Latest testen lassen. Sinnvoll ist dazu auch ein topic hier im Tester Bereic

[SKB]

@mcm1957 perfekt. Danke!

Habe zu den verschiedenen Versionen auch verschiedene Topics hier. Passt dann so!

[OliverIO]

@skb

Aus meiner Sicht sind die Versionen auf GitHub für die normalen User vollkommen egal.
Nur im Ausnahmefall forderst du den User
Direkt von GitHub etwas zu installieren.

Für stable und beta sind nur die Versionen die bei NPM existieren relevant.
Dort publishe ich nur wenn das auch eine Version für die beiden repos sind.

Daher ich benütze das Release Script nur wenn es einen echten publish nach NPM geben soll.
Ansonsten mache ich nur normale commits und push’s nach GitHub.

Auch das stößt auf GitHub die Tests an.
Nur das Release Script löst von GitHub aus den publish nach NPM aus

[SKB]

@oliverio sagte in Wie am Besten mit den Versionen bei Github umgehen?:

Nur das Release Script löst von GitHub aus den publish nach NPM aus

Nicht ganz. Das Release-Script erkennt Alpha und Beta Versionen und pusht diese zwar nach NPM aber sie sind darüber nur mit Angabe der Version installierbar.

[OliverIO]

@skb

Ah ok,
Ich mache keine Alpha Beta etc Versionen

Getestet wird von mir,
Dann im NPM repo durch die User
Und wenns kein Gemeckere gibt nach
Einiger Zeit ins stable

[SKB]

@oliverio Ah, ok.

Naja, ich code Adapter noch nicht so lange und demnach habe ich jetzt viel verändert und das würde ich dann gerne auch mal von Anderen ansehen lassen ;)

[OliverIO]

@skb

Mcm macht Code Review bevor er ins beta repo geht.
Ansonsten kannst du ja im Forum fragen.
Wenn du Lust hast kannst mich auch fragen

[SKB]

@oliverio Danke, einfach mal nach "energiefluss-erweitert" gucken. Da gibst einen Alpha Thread zu ;)

[OliverIO]

@skb sagte in Wie am Besten mit den Versionen bei Github umgehen?:

• du verwendest im adapter fs.writefile, es sollte die iobroker funktion verwendet werden, so das es mit redis usw. kompatibel ist.

• für besseres datum/zeithandling kannst du mal momentjs anschauen

• warum hast du hier das await vor await this.setStateChangedAsync main.js 484-454?
  Die Funktion ist zuende und danach kommt nix mehr. daher kannst das await auch weglassen

• JSON.parse(JSON.stringify(obj)) kann man neuerdings auch mit {...obj} austauschen. es wird jeweils ein neues obj erstellt, welches keine referenzen mehr auf das ursprungsobjekt hat (zumindest auf der ersten ebene). wenn tiefer weitere objekte sind, dann die nicht.

• warum hast du so einen großen tab-space (also das einrücken von code) von 8? 2 oder 4 reichen vollkommen

• in 2 (oder mehr) ebenen verschachtelte ifs kannst du in einem zusammenfassen, wenn es da nicht mehr fälle unterschieden werden 849-851 und später

• manche funktionen sind sehr groß, ich kenne styleguides, wo eine funktion nicht mehr wie 20 zeilen anweisungen enthalten darf (aber so wie es dir genehm ist). ist kein muss, macht komplexen code aber les- und wartbarer

• 906/907, warum das Function-Statement? Ist das so ein Art interpreter? Ich seh es wird der Funktionsnahme ermittelt und dann ausgeführt
  -functions ist zu mini zum anschauen :)

• irgendwie kommen mir viele code teile zu kompliziert aufgebaut vor. evtl kannst du, wenn du vscode verwendest, mal diese kostenlose ki-erweiterung https://codeium.com/ laden. da gibt es eine refactor funktion. da kannst mal schauen, was die dir vorschlägt einzelne funktionen zu optimieren.

• auch haben sich mir manche funktionen nicht wirklich erschlossen, allerdings hab ich nur den code angeschaut, ohne mir den adapter zu installieren und auszuprobieren.

alle punkte sind nur ideen, nach denen du mal schauen könntest.
wenn dir dein aktueller codestyle lieber ist, alles gut. ich gehe mal davon aus, das du noch nicht so lange programmierst (zumindest in javascript). von daher ist es nicht so wild, wenn nicht alles kompakt und effizient aussieht. wichtig ist, das es funktioniert. optimieren kann man später immer noch,

[SKB]

@oliverio Danke für deine Ausführungen :)

Eigentlich programmiere ich "schon" mehr als 20 Jahre, aber immer mit älteren Dingen bzw. nicht beruflich (und auch meist nicht mit aktuellen Modulen, da man diese nicht immer kennt ;) )

Meinst Du Zeile 454 das await, weil danach eh nichts mehr kommt? ok, das kann man weglassen, ja.

JSON.parse(JSON.stringify(obj)) verwende ich, weil das Objekt verschachtelt ist bzw. bis zu 3 Ebenen haben kann.

Ich mag den Tab-Space - daher verwende ich den etwas größeren (ist man so gewohnt)

Du meinst aus:

if (operators.test(item)) {
	// Now, we need to check, if condValue is a number
	if (!isNaN(condValue)) {
	}
}

wird

if (operators.test(item) && !isNaN(condValue)) {
}

? Ok, das könnte man so machen - stimmt

Mit den komplexen Funktionen hast Du Recht - diese kann man auf kleinere Funktionsblöcke herunterbrechen - ich denke, das ist meinem Gedankengang geschuldet.

Das Function Statement evaluiert Statements aus einem JSON Objekt und prüft, welche Condition valide ist.
Beispiel:
Der Wert ist 10 und die Bedingung des Users siehst so aus:

{
    ">0": {
        "_comment": "Einspeisung",
        "icon": "mdi:transmission-tower-export",
        "color": "rgb(161,211,67)"
    },
    "<0": {
        "_comment": "Netzbezug",
        "icon": "mdi:transmission-tower-import?flip=horizontal",
        "color": "#F20E40"
    }
}

Dann wird hier jeder Block gegen diesen Wert geprüft und der Block genutzt, welcher am Besten dazu passt.

Die Erweiterung schaue ich mir mal an. Danke Dir!