Refactor to Interfaces and Enums #45
Conversation
|
Intanto grazie! Rispondo ad un po' di punti.
Mi devi lasciare un po' di tempo per studiare le modifiche prima di approvare tutto in un colpo, perché non sono poche... E devo anche capire se riesco a interpretarle corretamente essendo nuovo di Python.
Questo vorrei lo lasciassi com'era - se non ti scoccia - perché anch'io all'inizio volevo farlo a cicli di "n" minuti senza rompermi più di tanto. Poi però mi sono reso conto che la pagina interrogata spesso si pianta per più tempo. Mi pareva logica la sequenza fatta: 10, 60, 120 e 180 minuti per poi desistere per la giornata.
Utile. Userei lo stesso meccanismo di cui sopra, quindi ZIP non valido (che può avvenire credo anche se ne scarica mezzo, quindi un errore sostanzialmente di connessione) deve fare il retry come già fa ora (senza però un'eccezione distinta, proprio per quel motivo che mezzo file comunque è un errore per me).
Ecco questa cosa volevo farla da tempo e la sto testando in locale (anche se per capire bene se funziona la devo buttare per forza qua). Se mi dai il tempo di implementare quella che ho trovato, vorrei usassimo quella. Aggiorna pure il manifest.json e anziché elencare i commit nelle release mette solo le PR.
Hai ragione e infatti la GitHub Action che volevo usare "obbliga" a fare questo proprio perché crea la release automaticamente una volta che si fa la PR nella
Qui mi dovrai dare una mano, perché non me ne intendo molto. Dammi solo il tempo di preparare la Action mettendo i tag anche nelle versioni precedenti (vediamo se riesco a fare casino) e magari se puoi sistemare quelle due cosette qui sopra ti ringrazio. P.S.: Ah, direi poi di usare l'italiano anche per le modifiche e i commenti, visto che questo progetto per sua natura è italiano e non ha senso esportarlo in altre nazioni (che se ne fanno del nostro PUN? 😄). P.P.S.: Sono riuscito a capire come fare quanto avevo scritto QUI e pare sia possibile! |
|
Ciao, allora, tranquillo per le changes, prenditi il tempo che ti serve e se hai dubbi chiedimi pure, ho fatto la draft apposta!
in teoria posso modificare il timer per farlo combaciare con i vecchi tempi, non sapevo del fatto che il sito desse problemi cosi importanti, magari quello nuovo sara' meglio, comunque nel caso preferissi proprio la vecchia forma lo rispristino no problem.
Per il fattore ZIP si alla fine non cambia molto, li ho divisi piu' che altro per avere un errore concreto nel momento in cui l'API ritornasse qualche errore di auth o cose simili, in modo da avere un avviso piu' preciso, effettivamente uno zip non valido non e' molto diverso da un errore generico, implemento la change e metto la logica normale anche in questo caso.
per le actions assolutamente, tolgo la mia, se vuoi fare un branch e fare una draft se mi metti come collaboratore magari posso darti una mano :) ps. ho aggiunto un badge nel readme per pescare l'ultima versione ;) per il format style usando vscode e ereditando l'env di HA ha gia' linter ecc settati, nel caso ti posso spiegare come impostarlo 👍 Per l'italiano si perdonami ho iniziato in italiano poi mi sono perso, e' l'abitudine, cerco di mantenere l'italiano 😅 Si avevo cercato qualcosa e avevo mezzo provato ad aggiungere la selezione del sensore di energia dalla config ma ho pensato che gia' questo era un cambiamento abbastanza grande, meglio farlo per step 😁
In realta' e' tanto che uso l'integrazione e come avevo gia' detto mi ero fatto sensori ecc per calcolare le cose e volevo gia' provare a contribuire da un po', ma non avevo molto tempo per mettermi abbastanza da capire bene come funzionasse, adesso che mi sto iniziando a liberare un po' ti aiuto volentieri :) |
Ottimo!
Facendo i test avevo visto questa cosa, non gli piace ricevere troppe richieste quando non va. Delle volte succede anche nelle ore serali, trovo nel log il fatto che ha mancato il primo download e poi anche il secondo; per questo avere i tempi più "larghi" di solito aiuta ad avere un prezzo aggiornato al giorno.
Lo spero, dopotutto era difficile fare peggio 😄
Direi di mantere questa divisione, l'importante è che riprovi a tirare giù tutto poi, con la stessa logica di retry di prima.
Intendi fare una branch e mettere lì i file di configurazione dell'Action di GitHub?
👍
Fai te che per scrivere/testare l'ambiente usavo VSCode dentro una VM Ubuntu messa su velocemente solo per fare quello. Però non sono mai riuscito a sfruttare il linter, forse perché non ho scaricato tutta la build di HA Core, io volevo solo fare l'integrazione e quindi quello che consigliano loro: python3 -m script.scaffold integrationnon mi funzionava perché non avevo appunto tutto il pacchetto. E le modifiche le ho sempre fatte lì perché ho visto che si riesce a saltare di versione più velocemente che con Docker (che invece uso in produzione, sul QNAP).
Anch'io negli altri progetti 😃 (commento sempre in inglese anche nei miei file personali) ma qui visto che possiamo teniamo 🇮🇹 .
Assolutamente, questo per la versione 2 o 3. Al momento sistemiamo quello che c'è, anche perché a parte il "core" di calcolo la parte noiosa è fare la Config UI, non volevo renderla troppo difficile. Ma vedremo in futuro.
Grazie, il tempo è sempre la risorsa più scarsa in assoluto anche perché io ho la tendenza ad aprire molti progetti e a chiuderne nessuno, ecco perché questo è così scarno. Almeno funziona 👍 e come dice il mio capo quello che non c'è non si rompe! |
Va benissimo allora allungo i tempi come prima no prob.
Top, correggo!
Si volendo si altrimenti in teoria puoi pushare le tue modifiche direttamente in questa draft, dovrei averti dato permesso di modifica, pero' dipende come' a livello di codice, se e' solo l'action puoi caricarla qua almeno mergiamo tutto insieme, l'unica cosa crea prima l'ultimo tag che hai effettivamente settato a mano, cosi' l'action riprende da quella versione, possiamo anche fargli fare una pre-release per questo merge, cosi' testiamo se fa' tutto bene e possiamo farla testare a chi vuole con il canale beta, se tutto va' bene possiamo poi fare la stable che arriva a tutti. Per i calcoli si la roba dell'UI va' pensata bene perche' sono un sacco di valori e se dobbiamo farlo bene bisogna stare attenti a validazione, possibili edge cases o tutte le possibili entita' che potrebbero gestire i valori di consumo, magari qualcuno ha il consumo totale giornaliero, alcuni solo l'attuale o chissa che altro Comunque si ultimamente hanno fatto un bel po' di changes, pero' alla fine non posso avercela troppo, stanno facendo un lavoro del cristo e HA e' diventato veramente lo state of the art per quanto riguarda la smart home, il fatto che facciamo parte del consorzio che gestisce Matter e' clamoroso per una no-profit FOSS (considerato che anche Apple ne fa' parte) ahahahah
ti capisco ahahahaha avevo iniziato cosi' la prima volta, e non ci stavo capendo nulla, poi ho realizzato che ci dev'essere un ambiente apposta ( i dev dovranno fare development quindi devono usare un env perforza ahahaha) Se hai usato docker non dovrebbe essere difficile, con Windows hai necessariamente bisogno del WSL2 installato e attivo, docker configurato per usare il wsl (dovrebbe chiederlo in automatico quando lo installi, o nelle impostazioni puoi attivarlo) e ovviamente git fai il fork di core, e da inserisci il link del tuo fork nel field apposta e fai apri Ti apre automaticamente VSCode e con Docker crea la folder di hassio core su un container che puoi usare attraverso VSCode Remote, teoricamente da' l'avviso in automatico del fatto che hai creato un remote e ti chiede di connettersi. Una volta connesso al remote puoi runnare, debuggare e editare un istanza di hassio nel container e accederci normalmente da homeassistant.local, e hai direttamente i task di development integrati su vscode. (run-safe, install deps, lint, format ecc) Una volta che sei nel remote puoi semplicemente creare una nuova cartella nella parent del core e farci un workspace dentro, Comunque ci mancherebbe, mi sembra il minimo che possa fare per contribuire ad un progetto che comunque uso ed e' molto piu' comodo di 1000 alternative Closed source, non avendo i milioni (neanche le centinaia ngl) da poter donare almeno aiuto in qualche modo 🤣🤣 |
|
Ah mi sono scordato di scrivere nel PR che abbiamo anche droppato bs4 come dependency, visto che usiamo l'API non dobbiamo piu' fare scraping 👌 |
Prova a dare un'occhiata, ho creato una branch Poi chiaro che magari qui non è che facciamo chissà quante PR, però alla fine il changelog è meglio scriverlo a mano.
I tag in realtà li avevo sempre fatti (se controlli ci sono), solo che non facevo le release. Mi piacerebbe - non so se sia possibile - preparare le draft release anche dei tag precedenti, così da averle come storico. Solo che non so come si fa!
Questo non ho (ancora) capito come si fa...
Vero vero, non intendevo gettare fango... però sarà perché non sono del mestiere io ma la documentazione non è proprio chiarissima. Sembra Google con Android, dove per capirci qualcosa devi guardare il sorgente!
Ecco, non volevo usare WSL2 in Windows (e uso Docker solo nel QNAP per far girare HA). |
|
hmmm, beh in teoria VSCode usa docker, quindi anche se lo hai sul Qnap dovrebbe farti spinnare un container nuovo di development usando Remote via SSH, pero' non ricordo bene come si fa', cerco e magari ti linko qualcosa 👌
nono, e' proprio atroce per il development ahahah la parte User e' super documentata (piu' o meno) ma quella dev e' tragica.
in teoria basta segnare la release come pre-release e impostare il tag con beta ed esce nel canale beta. Si i tag avevo visto ma pensavo fossero indietro rispetto all'attuale sorry 😅
precisa, il comando python era la parte che sapevo che si poteva fare ma non avevo ancora capito ahahahah Comunque mi hai invitato come collaboratore su tutta la repo, era quello che intendevi fare? |
Mm questo non mi quadra, perché nel QNAP ho solo HA Core, non tutto il sistema di sviluppo con VSCode.
Ah, figo! Mai provato finora.
Mancavano solo gli ultimi due (che ho aggiunto) dei quali m'ero scordato 🤦♂️
Ecco in realtà no, però non ho capito come aggiungere un collaboratore ad una singola branch... Come dici, mi sa che non si può fare (almeno con la versione gratuita di Github). Però ho bloccato la master richiedendo una review obbligatoria, non so se questa cosa funzioni, stiamo andando un po' troppo sul difficile per le mie conoscenze / ricerche su Google 😥 Io non vedo permessi, c'è un tutto o niente. Tecnicamente cosa puoi fare, qualsiasi cosa? Suggerimenti?
Ah, non avevo inteso; avevo provato a mettere in pratica il primo commento dove suggerivi di aggiungerti come collaboratore, solo che appunto non ho trovato il modo di farlo ad una branch, non vedo proprio l'opzione 🤷🏻♂️ |
beh tecnicamente puoi fare tutto sulla VM , non ci pensavo ma per tanto cosi' installi docker sulla VM e fai la stessa roba😅 si scusami non volevo aggiungere complessita', poi github ha i suoi quirk con release ecc, tecnicamente ho i permessi per pushare e fare branch e credo anche chiudere gli issue? comunque in caso ci volessimo sentire un po' meglio, per eventualmente discutere di qualche change ti lascio la mia mail principale, su questa ho meet, google chat, ecc (quella di github e' vecchia non ho linkato i servizi aggiuntivi) |
Secondo me sì.
Figurati se lo so io 😆, ci faremo esperienza! |
|
Ok allora, ho tenuto la logica del timer ma ho messo i tempi come prima e incluso il caso dello zip o qualsiasi altro errore nella connesione. piu' qualche roba qua e la' C'era altro da sistemare? te hai avuto modo di darci un occhiata? Per le action ho trovato gia' un edge case in cui bisogna stare attenti, se abbiamo un mismatch tra tag e release l'action fa' lo zip della repo allo stato dell'ultimo tag senza una release, non ne crea uno nuovo. Se per esempio abbiamo un tag 2.0.1 ma non ce' una release corrispondente, quando mergiamo una PR invece di creare il tag 2.0.2 e fare la release di quello, fa' la release del 2.0.1 e non include i change della PR, pero' li' include nel changelog! Quindi gia' per fare il merge di questo PR bisogna creare prima una release ufficiale, tipo 0.9.1, cosi' HACS inizia a seguire il versioning, e se facciamo una pre-release non esce se non selezioni beta. Ma soprattuto l'action quando fa' la draft release e crea il tag, ne crea uno nuovo, invece di farti la release per l'ultimo tag senza release, che sarebbe l'ultimo che hai creato visto che non abbiamo release. E' un po' convoluto, spero sia chiaro 😂 |
Non ho ancora avuto tempo nel dettaglio, l'avevo guardato all'inizio prima che facessi la PR.
Non sono sicurissimo di aver capito, però se invece è così i tag tecnicamente non lo crea il fatto di aver messo la label major/minor/patch? Quindi noi non definiamo nella PR la versione vera, ma diciamo solamente se è una major o minor. Dopodiché tutte le PR che verranno dopo saranno "automatiche". Direi di procedere così, se sei d'accordo, in quest'ordine:
|
Tranqui era giusto per sapere :)
Piu' o meno, non ho provato tutte le variabili, ma basta sapere che l'ultimo tag deve avere una release associata, altrimenti non sembra crearne uno nuovo (nel mio caso la differenza di tag era la stessa della label, il tag 2.0.1 esisteva gia' ma la release no, esisteva pero' la release e il tag della 2.0.0, ho fatto il merge con la label patch e invece di fare il tag e la release della 2.0.2, ha fatto la release della 2.0.1 e basta) Per le vecchie release in realta' basta fare solo l'ultima allineata con il master, in modo che dal momento in cui fai il merge delle action inizia a creare update Modifico la task list nel tuo commento cosi ne abbiamo una sola effettiva Edit: Il fix per #44 hai gia' un idea? basta fare un try except sull'import e utilizzare il vecchio metodo? Per la questione delle commit come si fa'? non ho mai fatto uno squash o un prune, tu? 🤣 |
Però le volevo creare lo stesso, a mo' di storico delle funzionalità implementate.
Vedi che hai i grossi poteri! 🤣
Pensavo una di queste due, però al momento non ho avuto tempo di buttarmi su le due versioni (pre e post) per vedere come si comportano:
Nel caso fosse vero, esegue le istruzioni come sono ora, altrimenti le vecchie (per Holidays immagino si possa semplicemente ignorare visto che in precedenza non dava errori).
L'avevo fatto solo in locale, praticamente ti esce un editor dove riordini le commit e puoi decidere quali raggruppare (ovviamente tu sai/ti ricordi cosa contiene ciascuna). Immagino che poi sparando su GitHub brucierà le varie commit ma non credo sia un problema. Da provare! |
|
ah ok, provo da vscode o da gh desktop allora, thanks 👌
hmm devo provare a vedere se posso spinnare una vecchia versione con i devcontainer, non sono sicuro.
ahahahah si lo stavo copiando e ho visto che me lo faceva riordinare, a sto punto mi son detto lo scrivo li 😅
Volendo si puo' fare uguale, pero' penso che sia meglio fare prima l'ultima release e settarla come latest, in modo che facciamo passare hacs alle release e tag, poi fare le vecchie stando attenti a deflaggare il setta come latest, cosi' evitiamo che magari nel momento in cui si crea per esempio la v0.4 anche chi e' sul main riceve un update che e' effettivamente un downgrade 😂 |
Con il metodo che usavo nella VM Ubuntu si può, ed è quello descritto nella documentazione che però non è il devcontainer.
Bene, approvato 👍
Ottimo 👌 |
|
Stasera vedo se riesco intanto a fare il merge della PR #46 e impostare la release, completando le prime due spunte. |
|
Le release sono perfette, ho aggiornato ora e da' anche tutta la lista di vecchie versioni, e abbiamo anche il toggle per le versioni beta o per fare il downgrade 🎉 ho fatto un paio di tentativi di squash oggi pomeriggio, credo di essere pronto per farlo sul master ora 😂 |
semplificazione dei blocchi condizionali spostata logica per trovare la data del prossimo cambio fascia in get_next_date, snellendo la funzione get_fascia
added vscode env to gitignore add logger for future use change in return types to match expect type or fn type return ordering and cleanup of imports
Imports are already pruned for new code, so there are missing import in this file!
Eh, appunto, ma io non ho quella folder
L'hai creata tu? Come? |
nono il file del devcontainer non l'ho toccato. ah ok allora la cartella l'ho creata da vscode sicuramente, se sali di un livello ti da' tutte le cartelle di linux, entra in workspaces e da li aggiungi la cartella affianco a quella core, pensavo ci fosse di default 😅 |
| @@ -205,12 +204,9 @@ async def update_fascia(self, now=None): | |||
| ) | |||
|
|
|||
| _LOGGER.info( | |||
| "Nuova fascia corrente: F%s (prossima: F%s)", | |||
| "Nuova fascia corrente: F%s (prossima: F%s) \nProssimo cambio fascia: %s", | |||
There was a problem hiding this comment.
Insisto con il non creare una riga aggiuntiva (\n), ma invece:
"Nuova fascia corrente: F%s (prossima: F%s alle %s)",
visto che è solo una data/ora in più e si riferisce già alla fascia.
There was a problem hiding this comment.
ah okok sorry non avevo capito 😅
C'è sicuramente qualche altro passaggio che manca. Da VS Code di certo non posso farla, perché secondo me quella lì è dentor al container... ma ad un altro livello. Se la creo sotto la root del container, come vedi, non va a finire sotto a
... bensì dentro a
Oltretutto se la confronto con la tua, il tuo container non si chiama
|
Sisi infatti dev'essere allo stesso livello di "core", magari mi sono spiegato male io 😅 il nome non so perche' sia diverso, magari l'ho cambiato quando ho clonato la repo 🤔 purtroppo per avviare effettivamente HA devi comunque aprire 2 finestre di VScode, una con il core e una con la repo 🥲
Io di solito lo spengo da homeassistant cosi' controllo che esca senza errori prima di chiudere vscode, pero' in teoria anche chiudendo vscode dovrebbe farlo in automatico EDIT: per creare la cartella puoi fare tasto destro in un spazio vuoto e fare crea cartella, oppure un mkdir dal terminale |
Rimosso override che causa problemi; fix virtualdj#51
Sicuramente non sono in grado io, ma la cartella l'ho creata nel container e ho fatto Open Folder come suggerivi partendo dal container principale aperto.
Quindi va il lint, ma neppure bene perché mancano le dipendenze. Di peggio però c'è che se tento di aprire un'altra finestra (File > New Window) e lì caricare il devcontainer principale mi si inchioda tutto e comunque, secondo me, non carica il componente anche se riuscissi a lanciare HA. Questo perché non lo vede... come fa a sapere che esiste (non è nelle sue sottocartelle) se HA lo devi lanciare dal container principale? Secondo me hai configurato qualcos'altro, perché oh... non riesco a farlo andare in nessun modo. |
Eh il metodo e' corretto pero', magari hai dedicato poca RAM all VM? potrebbe anche essere che due layer di virtualizzazione gli diano fastidio, pero' mi sembra improbabile. Gli import devi installarli te dal terminale con
Infatti per usarlo su HA devi o copiare i file te dentro la cartella custom components che e' dentro il core, oppure installi da HACS come faresti normalmente. Perche' sono due ambienti divisi quello del core e quello dell'integrazione, non sono connessi, condividono solo gli stessi site-package, eseguibili di python e le impostazioni di VSCode, pero' non si vedono a vicenda, i file che hai nel core sono divisi da quelli dell'integrazione |
Ho assegnato 16 GB alla VM, speravo fossero sufficienti 😄
Ah OK, ma allora non c'è tutto l'automatismo che speravo...
Allora mi son fatto un'idea sbagliata del devcontainer. Io credevo si occupasse lui di tutto, anche perché per fare il debug (es. mettere un punto di interruzione sulla routine del coordinator) se lo copi dentro manualmente non so se riesci a farlo. Ma a questo punto, se devo installarlo dentro a mano, tanto vale fare il mount della cartella Git dell'integrazione all'interno di
Quindi in sostanza tu lanci sempre il devcontainer principale di HA (quello che ha i task) mentre su quello della "folder" dell'integrazione praticamente usi solo il lint... |
In effetti 🤣
eh ma secondo me l'utilita' sta nell'installarlo da HACS invece, cosi' hai modo di testare il processo di installazione come se fosse in prod. Magari ce' un modo di fare una sorta di ibrido su linux, sto resuscitando la mia distro di Arch, appena riesco provero' a trasferire lo sviluppo li' quindi sicuro avro' modo di approfondire un attimo la cosa per bene
Si esatto, per la roba del linting, formatting ecc non capisco, eppure a me ha preso tutto in automatico, pero' appunto ho un setup con 13mila cose configurate, magari avevo gia' delle dipendenze che non sono segnate nelle istruzioni, ricordo di averci smanettato un po' ma non ricordo niente di particolare |
|
|
||
| # Crea i sensori (legati al coordinator) | ||
| # Crea i sensori dei valori del pun(legati al coordinator) |
There was a problem hiding this comment.
Spazio prima della parentesi mancante, nel commento.
| case Fascia.F23: | ||
| self.entity_id = ENTITY_ID_FORMAT.format("pun_fascia_f23") | ||
| case _: | ||
| self.entity_id = "none" |
There was a problem hiding this comment.
"none" dovrebbe essere in realtà None, come sotto.
| return None | ||
| if self.fascia: | ||
| return f"PUN fascia {self.fascia.value}" | ||
| return "None" |
There was a problem hiding this comment.
Idem: "None" diventa None (eventualmente modificando la dichiarazione del tipo di funzione con | None?)
| @@ -232,35 +233,39 @@ def options(self) -> list[str] | None: | |||
| @property | |||
| def native_value(self) -> str | None: | |||
| """Restituisce la fascia corrente come stato""" | |||
| return decode_fascia(self.coordinator.fascia_corrente) | |||
| if not self.coordinator.fascia_corrente: | |||
| return "None" | |||
|
Ciao, scusami l'assenza ma ho iniziato un nuovo lavoro e sto avendo un bel po' da' fare 😅 Se riesco per questo weekend cerco di fare tutti gli edit dei commenti 👌 in teoria non c'era rimasto altro giusto? ps. ridendo e scherzando tra 3 mesi chiude il vecchio sito comunque 😂 |
Ciao, nessun problema, ho avuto casini anch'io altrimenti mi sarei dato da fare...
Esatto, solo modifiche minori alla fine.
Fanno sempre presto a cestinare le cose che funzionano! 😄 |
|
FYI ho trovato questo portale a livello europeo che pare raccogliere i dati relativi energia. EDIT: Qui pare essere indicato come richiedere accesso alla piattaforma REST: |
|
Se interessa mi hanno risposto da ENTSO-E con una serie di informazioni per l’ascesso ai dati: You can export data from Transparency Platform using the following channels: In order to use REST API, SFTP, Subscriptions, or export functionality of the GUI you need to be a registered user. Please note that some of the data is not freely available. Please refer to the Terms & Conditions and the list of data which can be freely re-used. Could you please confirm if you have other questions? Kind regards, |
|
@g1za Ammetto che ieri ho avuto veramente poco tempo, ma io non ho trovato in quel sito il valore del PUN. Sicuro che ci sia? |
|
No, non ho la certezza. Ho dato un’occhiata veloce pure io ma non l’ho trovato. Però ho visto in alcuni report che l’ente ne parla. Mi parrebbe strano visto che ci sono tutti gli altri e da quello che ho capito i dati arrivano da Terna. Posso sempre provare a mandare un messaggio all’assistenza e vedere se mi rispondono. |
|
Sfortunatamente non pubblicano i PUN :( |
Reasoning:
Vista la discussione riguardante il calcolo del prezzo totale della bolletta, i possibili cambi riguardo i prezzi e l'attuale mancanza di un metodo per impostare un tipo di contratto (il prezzo della fascia corrente e' sempre basato sul multifascia, mentre dovrebbe essere basato sul tipo di contratto (mono/bi/multi)
Ho quindi migrato parte del programma a una struttura OOP implementando Interfacce per poter definire le strutture di dati e rendere il check e la modifica delle stesse piu' semplice e intuitivo.
questo aiuta anche nell'auto-complete in IDE e aggiunge un livello di typesafety per le funzioni da chiamare.
Una lista dei cambiamenti piu' rilevanti:
RELEASE:
Ho aggiunto una Github Action che Bumpa e crea una versione nelle release per ogni push/PR sul master, purtroppo per ora non sono riuscito a trovare un modo per fargli bumpare anche la versione in manifest.json, quindi abbiamo un mismatch tra le due, ma non comporta reali problemi in quanto HACS prende il numero nelle release di github.
Inoltre cosi' facendo e' possibile distribuire versioni beta in pre-release.
E' consigliato utilizzare un branch e fare un PR invece che pushare sul main direttamente, in questo modo e' possibile modificare il tipo di release (major, minor, ecc) dalla PR label, e ci permette di avere pre-release in beta durante il testing
Per maggiori info sull'azione o su i parametri che si possono modificare attraverso il commit message vedere:
https://github.com/marketplace/actions/tag-release-on-push-action
Altre modifiche non fuzionali:
Changes description:
Files:
Coordinator:
Interfaces:
Sensor:
Enum
Utils: