Wie am Besten mit den Versionen bei Github umgehen?
-
@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
-
@mcm1957 perfekt. Danke!
Habe zu den verschiedenen Versionen auch verschiedene Topics hier. Passt dann so!
-
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 -
@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.
-
Ah ok,
Ich mache keine Alpha Beta etc VersionenGetestet wird von mir,
Dann im NPM repo durch die User
Und wenns kein Gemeckere gibt nach
Einiger Zeit ins stable -
@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
-
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 -
@oliverio Danke, einfach mal nach "energiefluss-erweitert" gucken. Da gibst einen Alpha Thread zu
-
@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, -
-
@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!
