Meta.pm: Metadaten über FHEM Module

Begonnen von Loredo, 19 Februar 2019, 11:43:50

Vorheriges Thema - Nächstes Thema

DS_Starter

Danke Julien,

eine weitere Frage ist mir aufgekommen.
Es sind für DbLog auch Datenbankbinaries nötig wie sqlite3 oder mysql-server bzw. mysql-client. Macht es Sinn dies ebenfalls irgendwie mit anzugeben ?

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

#76
Zitat von: DS_Starter am 07 April 2019, 07:42:31
Danke Julien,

eine weitere Frage ist mir aufgekommen.
Es sind für DbLog auch Datenbankbinaries nötig wie sqlite3 oder mysql-server bzw. mysql-client. Macht es Sinn dies ebenfalls irgendwie mit anzugeben ?


Cher H*eiko  ;)


Ja, angedacht ist sowohl die Angabe von APT Paketen als auch das Vorhandensein bestimmter Binärdateien zu prüfen.
Ich bin mir noch nicht 100% sicher wie ich dabei mit redundanten Angaben umgehe, auch die Angabe von Perl Libs als Apt Pakete zusätzlich zur eigentlichen Perl Abhängigkeit ist etwas problematisch. Nicht umbedingt für die spätere Auflösung/Installation, aber vor allem für eine verständliche Darstellung. Schließlich ist es in der Regel keine "und", sondern eine "oder" Angabe. Aber wenn es dann doch mal eine "und" Angabe ist, dann weiß ich eben noch nicht, wie ich damit umgehen soll :-/


Ebenfalls angedacht ist die Angabe von notwendigen sudo Berechtigungen, File Ownerschaft (chown) und File Berechtigungen (chmod). Jedoch möchte ich zunächst einmal die reinen Perl Abhängigkeiten End-to-End fertig haben, also inkl. Installation und als ersten Use Case für die Kooperation mit einem Schwester-Modul die Auflösung der Node.js Abhängigkeiten.


Ich muss glaub ich mal den Bugtracker befüllen, um die offenen Punkte auch präsent zu haben ;)




LG
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

Hi Julian,

na da wird sich ja noch einiges tun.  ;)
Mit der Angabe vom Binaries warte ich mal bis du soweit bist um sie dann in der richtigen Art und Weise angeben zu können.

Für die Verlinkung zur DEV-Version von DbLog habe ich jetzt einen solchen Eintrag zum contrib erstellt:


  "resources": {
    "x_wiki": {
       .....
    },
    "repository": {
      "url": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter",
      "web": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter/93_DbLog.pm",
      "type": "svn"
    }
  }


Wäre das richtig so, oder würdest du es anders tun ?

LG,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

Ich habe mir jetzt nochmal überlegt, wie man das Changelog mit integrieren kann.
Hier mal ein Vorschlag fürs Format:




  "x_changelog": {
    "2019-04-13": {
      "version": "v0.4.3",
      "release_notes": [
        ""
      ],
      "upgrade_notes": [
        ""
      ],
      "bugfixes": [
        ""
      ],
      "changes": [
        ""
      ],
      "new_features": [
        ""
      ]
    },
    "2019-04-12": {
      "version": "v0.4.2",
      "release_notes": [
        ""
      ],
      "upgrade_notes": [
        ""
      ],
      "bugfixes": [
        ""
      ],
      "changes": [
        ""
      ],
      "new_features": [
        ""
      ]
    }
  }



Als Major Key muss hier wohl das Datum her, damit die Angabe der Versionsnummer optional bleiben kann.
Angedacht ist aber, dass, wenn man die Versionsnummer im Changelog führt, die Angabe der Version als Metadata optional sein kann. Allerdings ist man dann natürlich gezwungen bei _jedem_ Update auch den Changelog zu führen. Wer das nicht möchte, könnte dann die unabhängige Versionsnummer extra pflegen. Wenn man nirgends eine Versionsnummer angibt und sich ganz auf die SVN Versionierung verlässt, ist es quasi ein kompletter Ersatz für die CHANGED Datei, nur auf Modulebene. Allerdings wertet der FHEM Update Befehl natürlich keine Metadaten aus, das wird dann nur der FHEM Installer tun. Wahrscheinlich muss man dann trotzdem noch die Infos auch in die CHANGED Datei packen, wenn man möchte, dass auch Nutzer des Update Befehls die Information sehen.


Die unterschiedlichen Kategorien sind dann alle optional, aber mindestens eine der Kategorien muss mit mindestens einem Text befüllt sein.
Dabei hatte ich - angelehnt an dem, was in CHANGED schon so getan wird - folgende Gedanken:


release_notes --> verständliche Erklärung/Zusammenfassung in Form eines Fließtextes für den User
upgrade_notes --> zusätzliche Erklärung über Implikationen von inkompatiblen Änderungen. Womöglich muss der User etwas von Hand tun und der Installer würde später wahrscheinlich verlangen, dass diese Hinweise vor dem Update/Upgrade bestätigt würden.
bugfixes --> einzelne Bugfixes; kann VCSLOG(SVNLOG) entsprechen, ist aber manuell zu pflegen und muss somit nicht so übermäßig detailliert sein (immerhin gibt es dafür ja das VCS).
changed --> Änderungen/Verbesserungen an bestehenden Funktionalitäten
new_features --> Neue Funktionalitäten




Any comments?
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

#79
Zitat von: DS_Starter am 13 April 2019, 12:58:48
Für die Verlinkung zur DEV-Version von DbLog habe ich jetzt einen solchen Eintrag zum contrib erstellt:


  "resources": {
    "x_wiki": {
       .....
    },
    "repository": {
      "url": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter",
      "web": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter/93_DbLog.pm",
      "type": "svn"
    }
  }


Wäre das richtig so, oder würdest du es anders tun ?


Nee, damit würdest du die produktive Version anders verlinken.
Schau mal hier im META.json.full.txt Beispiel.


Bei mir nutzt das DockerImageInfo Modul diese Funktion bereits, da es mein bisher einziges komplett extern gehostetes Modul ist:
https://github.com/fhem/fhem-docker/blob/dev/src/99_DockerImageInfo.pm


Da hast du ein gutes Praxis Beispiel, wenn ein Modul gar keine Daten über das SVN verwaltet. Wenn man also ein im SVN verwaltetes Modul so wie deins um weitere Metadaten anreichern möchte, ist sowas ein gutes Beispiel, um sich inspirieren zu lassen.
Der FHEM Installer soll später für solche Module auch ermöglichen anzugeben, von welchem Modul man die Entwicklerversion statt der Produktivversion verwenden möchte. Noch ist aber wie gesagt noch nicht ganz raus, ob dann für das Update auf die controls_*.txt komplett verzichtet wird oder ob es noch alternativ oder gar parallel unterstützt wird... Für den Moment ist es also nur eine einfache Möglichkeit in der Modul Informationsseite anzeigen zu lassen, wo man die Entwicklerversion laden kan.

Für dich wäre also richtig:



  "resources": {
    "x_wiki": {
       .....
    },
    "repository": {
      "x_dev": {
        "type": "svn",
        "url": "https://svn.fhem.de/fhem",
        "web": "https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter/93_DbLog.pm",
        "x_branch": "trunk",
        "x_filepath": "fhem/contrib/DS_Starter/",
        "x_raw": "https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbLog.pm"
      }
    }
  }


Hoffe das hilft :-)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

#80
Ich verwende zur Zeit in fast allen von mir betreuten Modulen eine solche Struktur:


# Version History extern:
our %DbRep_vNotesExtern = (
  "8.19.0" => "04.04.2019 The \"explain\" SQL-command is possible in sqlCmd ",
  "8.18.0" => "01.04.2019 New aggregation type \"year\" ",
  "8.17.0" => "20.03.2019 With new attribute \"sqlCmdVars\" you are able to set SQL session variables or SQLite PRAGMA every time ".
              "before running a SQL-statement with sqlCmd command.",
  "8.16.0" => "17.03.2019 allow SQLite PRAGMAS leading an SQLIte SQL-Statement in sqlCmd ",
  "8.15.0" => "04.03.2019 readingsRename can now rename readings of a given (optional) device instead of all found readings specified in command ",
  "8.13.0" => "11.02.2019 executeBeforeProc / executeAfterProc is now available for sqlCmd,sumValue, maxValue, minValue, diffValue, averageValue ",
.....


Die Versionierung und den Text pflege ich bei jeder Veränderung die für den User relevant ist. Links können ebenfalls mit integriert werden.
Die Versionsnummern mappe ich dann mit einer Sub in deine Meta-Struktur beim Restart von FHEM.
Dadurch muß ich nicht jedesmal alles doppelt pflegen.

Außerdem hat der User ein "get ... versionNotes" zur Verfügung um nachschauen zu können was sich in den einzelnen Versionen geändert hat.
In dem Text nach dem Datum steht dann alles drin, Bugfixes, neue Features etc. Aus einem zweiten Hash werden noch wichtige Infos wie Links zu Online-Hilfesystemen oder RFC-Dokumentationen angeboten.

Also ich würde "x_changelog" nicht so stark aufgliedern und außerdem die "version" als führende Information nehmen und dieses außerdem als "x_version" verwenden. Dann hat man keine Mehrarbeit (und ich könnte mein Mapping weiterhin nutzen  ;) ).

Danke für das DEV-Beispiel mit META.json.full.txt, studiere ich mal ...  :)

Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

Zitat von: DS_Starter am 13 April 2019, 13:23:07
Danke für das DEV-Beispiel, studiere ich mal ...


Hab dir das für dein Beispiel oben noch ergänzt.


Zitat von: DS_Starter am 13 April 2019, 13:23:07
Ich verwende zur Zeit in fast allen von mir betreuten Modulen eine solche Struktur:


Ich hab mir deine Struktur auch schon angesehen, aber es fehlen halt einige Use Cases zur Kompatibilität, siehe oben. Die manuelle Angabe der Versionsnummer möchte ich nicht als zwingende Voraussetzung verankern, nur um ein Changelog zu führen. Auch die Abhängigkeit zu x_version macht gar keinen Sinn, weil x_version eine generierte Angabe ist und das auch bleiben soll. Das manuell einzutragen ist sehr fehlerträchtig und auch gar nicht möglich, weil man die SVN Revision gar nicht im Voraus gesichert eintragen kann.


Habe auch schon länger vernommen, dass du die Versionierung manipulierst - keine gute Idee und generell keine Garantie, wie üblich, ne ;-p
(beispielsweise können Reload- und Update Situationen ggf. problematisch werden).


Die Aufteilung in verschiedene Änderungs-Kategorien erscheint mir äußerst hilfreich und insbesondere die *_notes Angaben dürften - wenn sie denn dann richtig befüllt sind - viel hilfreicher für den Nutzer sein als alles andere bisher. Links zu weiteren Infoquellen halte ich - ganz ehrlich - eher für überflüssig. Das sind keine Informationen, die einen Benutzer interessieren, sondern vielmehr einen Entwickler (oder wahrscheinlich sogar nur den Modul-Author selbst, um zu einem späteren Zeitpunkt die Entwicklung nachvollziehen zu können).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

ZitatLinks zu weiteren Infoquellen halte ich - ganz ehrlich - eher für überflüssig.
Kommt darauf an. Für die Nutzerverwaltung in der Synology Surveillance Station gibt es eine entsprechende Online-Hilfe des Herstellers. Der Nutzer sollte diese zur Verfügung haben, weil es eine wichtige Info zur Handhabung der Userrechte ist (SSCam).
Will damit sagen, so pauschal kannst du nicht einfach verneinen  ;)

ZitatHabe auch schon länger vernommen, dass du die Versionierung manipulierst - keine gute Idee und generell keine Garantie, wie üblich...
Naja, mag sein ... aber ich nutze es schon lange. Da war an ein Meta.pm noch nicht zu denken.  ;)
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

Zitat von: DS_Starter am 13 April 2019, 13:44:28
Kommt darauf an. Für die Nutzerverwaltung in der Synology Surveillance Station gibt es eine entsprechende Online-Hilfe des Herstellers. Der Nutzer sollte diese zur Verfügung haben, weil es eine wichtige Info zur Handhabung der Userrechte ist (SSCam).


Ich denke du vermischt hier zwei unterschiedliche Use Cases. Bezogen auf einen einzelnen Release braucht es IMHO wahrscheinlich eher keine Links.
Die Verlinkung auf generell weiterführende Informationen wie beispielsweise Hersteller Dokumentation ist absolut sinnvoll und kann z.B. als "Homepage" als Teil des sogar offiziell spezifizierten Zweigs resources angegeben werden. Aber natürlich ist "Homepage" streng genommen auf das FHEM Modul selbst zu beziehen, von daher könnte ich mir vorstellen, dass man noch einen x_vendor Bereich mit einführt und dann auch gesondert anzeigt (also Hersteller Homepage für die Hardware und dedizierter Doku-Link). Wäre das was?
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

ZitatIch denke du vermischt hier zwei unterschiedliche Use Cases. Bezogen auf einen einzelnen Release braucht es IMHO wahrscheinlich eher keine Links.
Gebe dir recht ... allerdings hatten wir uns diesbezüglich etwas missverstanden bzw. ich vermutlich nicht eindeutig geschrieben. Diese für den User hilfreiche Links kommen aus einem zweiten Hash und werden über ein "get ... userVersion hints" aufrufbar angeboten. Mit der eigentlichen Versionierung hat das auch bei meiner bisherigen Verwaltung nichts zu tun.

Zitat...von daher könnte ich mir vorstellen, dass man noch einen x_vendor Bereich mit einführt und dann auch gesondert anzeigt (also Hersteller Homepage für die Hardware und dedizierter Doku-Link). Wäre das was?
Klingt nicht schlecht. Meiner Meinung nach sollte es aber möglich sein nicht nur einen Link zu hinterlegen, sondern mehrere für die das Modul tangierende Themen/Infos.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo


Die Frage ist, ob solch ausführliche Infos nicht eigentlich (zumindest bisher) in die commandRef gehörten?


Aber mir ist auch schon durch den Kopf gegangen, dass der eigentlich ursprüngliche Zweck der commandRef als wirkliche Referenz, wie ich die set/get Befehle nutze, Attribute setze und Readings richtig deute, verloren gegangen ist. Von daher finde ich das hier tatsächlich gut aufgehoben. Für den breiten Nutzen wäre es aber langfristig hilfreich, wenn dann auch andere Modulautoren ihre commandRef aufräumten und die Zusatzinfos an die dann dafür geschaffenen Stellen verschiebten. Ich weiß, utopisch das zu glauben, aber vielleicht gehen wir mit gutem Beispiel voran. Schließlich versuchen wir es ja hier allen möglichst leicht zu machen alle Infos über/zu ein/em Modul zentral und maschinenlesbar zu hinterlegen. Ich sehe aber schon, dass für die Wiki Doku zusätzliche Hilfe notwendig ist...  :-[
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

DS_Starter

#86
ZitatIch sehe aber schon, dass für die Wiki Doku zusätzliche Hilfe notwendig ist...  :-[
Für den Anfang ja, später hat man das irgendwann "gefressen"  :D

Nochmal zum Thema DEV ...
Habe deinen Hinweis soweit übernommen, aber sollte es nicht

"x_branch": "dev",

heißen statt "trunk", weil mit trunk wird der Link zum Dev-File nicht erzeugt, mit "dev" klappt das wie es soll.
Weiterhin ist mir die Bedeutung von

"url":  ....

unklar. Denn egal was ich dort eintrage, sehe ich keinen Unterschied oder Veränderung zu generierten Links etc.
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

@Julian, kleiner Nachtrag von weiter oben.

ZitatAuch die Abhängigkeit zu x_version macht gar keinen Sinn, weil x_version eine generierte Angabe ist und das auch bleiben soll....
Das war meinerseits natürlich Blödsinn. Was ich meinte, dass du IMHO die "version", die du auch jetzt bereits integriert hast dort verwenden solltest bzw. dann diese im changelog integrierst damit man nicht doppelt pflegen muss.
Sorry für die Verwirrung  :)
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Loredo

#88
Zitat von: DS_Starter am 13 April 2019, 15:01:45
sollte es nicht

"x_branch": "dev",

heißen statt "trunk", weil mit trunk wird der Link zum Dev-File nicht erzeugt, mit "dev" klappt das wie es soll.


Nee schon "trunk", weils ja wirklich darum geht, in welchem Branch das File liegt. Wenns der selbe ist wie für die produktive Version und nur in einem anderen Verzeichnis, dann ist x_branch bei beiden Angaben natürlich gleich. Hatte ich aber irgendwie in 98_Installer komisch drin - jetzt sollte es passen.


Zitat von: DS_Starter am 13 April 2019, 15:01:45
Weiterhin ist mir die Bedeutung von

"url":  ....

unklar. Denn egal was ich dort eintrage, sehe ich keinen Unterschied oder Veränderung zu generierten Links etc.



Ja, das stimmt. "url" ist offiziell spezifiziert und ist der Link, unter dem das Repository Root liegt. Das muss nichtmal https:// sein, sondern kann auch svn://, git://, svn+ssh://, git+ssh:// etc sein. Zusammen mit x_branch und x_filepath kann man dann in der Tat das File im Repository adressieren. Das ist auch der Grund, weshalb die Repository Adresse im Installer in der zweiten Zeile nur angezeigt, jedoch nicht als HTML Anker verlinkt ist. Andere Protokolle als http sind stark vom Client abhängig und die Unterschiede mit "+ssh" Zusatz können die Browser dann sowieso schon nicht mehr richtig umsetzen...

Der Installer deckt nun aber noch zwei weitere Use Cases ab, weshalb der Link für die prod und dev Webansicht nicht generiert werden kann.
Beim Use Case "Web Ansicht" kann man (je nach Tool) nicht immer die ganze URL voraussagen. Deshalb hatte ich mich der Einfachheit dazu entschlossen, dass man dafür eine komplette URL hinterlegt statt in Einzelteilen.
Ähnlich ist es auch beim zweiten Use Case "Raw/Textansicht": Da "url" ja nicht unbedingt eine Variante über HTTP/S liefern muss, ist die RAW URL auch separat. Das hat auch den Vorteil, dass man im Prinzip für das Deployment nicht zwangsläufig den VCS Server hernehmen muss (aber natürlich kann). Dedacht war ja wie gesagt auch, dass man zukünftig möglicherweise auf controls_*.txt verzichtet und direkt die Haupt-Moduldatei zieht, META.json darin auswertet und dann entscheidet, was man weiter beim Update tut (ja, eine Liste mit dazugehörigen Dateien wäre dann natürlich auch im META.json unterzubringen). die "x_raw" Einträge könnten also dann zukünftig die URLs sein, die man als Einstiegspunkt in ein FHEM 3rd-party Source Repository nimmt.

Zitat von: DS_Starter am 13 April 2019, 16:23:54
@Julian, kleiner Nachtrag von weiter oben.
Das war meinerseits natürlich Blödsinn. Was ich meinte, dass du IMHO die "version", die du auch jetzt bereits integriert hast dort verwenden solltest bzw. dann diese im changelog integrierst damit man nicht doppelt pflegen muss.
Sorry für die Verwirrung  :)


Stand auch in einem Nebensatz von mir so bereits, aber ist nicht so offensichtlich bzw. wohl zu klausuliert :-)


Zitat von: Loredo am 13 April 2019, 13:05:55
Angedacht ist aber, dass, wenn man die Versionsnummer im Changelog führt, die Angabe der Version als Metadata optional sein kann. Allerdings ist man dann natürlich gezwungen bei _jedem_ Update auch den Changelog zu führen.


Betonung liegt hier auf "optional" ;)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

CoolTux

Hallo Julian,

Die letzten Tage gab es ja einige Probleme mit Meta.pm und ganz alten Installationen. Konnte den ein oder anderen auf heute vertrösten und das funktioniert nun auch wieder.
Allerdings gibt es bei Hue noch Meldungen


2019.04.23 08:33:04 1: PERL WARNING: Argument "2.91_01" isn't numeric in numeric lt (<) at FHEM/Meta.pm line 1791.
2019.04.23 08:33:39 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/31_HUEDevice.pm line 1293.


Vielleicht magst Du da mal schauen.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net