FHEM Forum

FHEM - Entwicklung => FHEM Development => Thema gestartet von: rudolfkoenig am 09 März 2018, 08:52:09

Titel: contrib/deprecated angelegt
Beitrag von: rudolfkoenig am 09 März 2018, 08:52:09
Ich habe contrib/deprecated angelegt, und das seit etwa 4 Jahre in deprecated Zustand befindlichen 98_JsonList.pm dahin verschoben.
Titel: Antw:contrib/deprecated angelegt
Beitrag von: betateilchen am 09 März 2018, 21:57:45
und das seit etwa 4 Jahre in deprecated Zustand befindlichen 98_JsonList.pm dahin verschoben.

Bist Du sicher, dass Du das getan hast?
Titel: Antw:contrib/deprecated angelegt
Beitrag von: rudolfkoenig am 10 März 2018, 10:00:55
Danke fuer den Hinweis, jetzt sollte die Datei tatsaechlich verschoben sein.
Titel: Antw:contrib/deprecated angelegt
Beitrag von: betateilchen am 10 März 2018, 11:41:12
ja, nun passt es.
Titel: Antw:contrib/deprecated angelegt
Beitrag von: rudolfkoenig am 10 März 2018, 14:32:02
Die naechsten Opfer: 82_LGTV.pm und 80_xxLG7000.pm auf Wunsch von Markus.
Titel: Antw:contrib/deprecated angelegt
Beitrag von: krikan am 10 März 2018, 19:48:09
Markus und Rudi könntet ihr bitte MAINTAINER.txt entsprechend nachziehen. Danke.
Titel: Antw:contrib/deprecated angelegt
Beitrag von: rudolfkoenig am 10 März 2018, 19:53:35
Habe JsonList beim LGTV Verschieben entfernt, sollte also im SVN sein, und morgen verteilt werden.
Titel: Antw:contrib/deprecated angelegt
Beitrag von: krikan am 10 März 2018, 20:14:07
Dann habe ich nicht begriffen, dass Contrib-Module wohl nur freiwillig und wahlweise in MAINTAINER.txt stehen!.

Was ist eigentlich mit 21_OWTEMP.pm und 20_OWFS.pm? Die sind seit Ewigkeiten als (deprecated) markiert und bevor ich mir jetzt summaries ausdenke...
Titel: Antw:contrib/deprecated angelegt
Beitrag von: Beta-User am 27 Januar 2020, 13:22:14
Eine Verständnisfrage noch:

Ich hatte das Modul "Heating_Control" "nur" nach contrib verschoben (Diskussion hier (https://forum.fhem.de/index.php/topic,99984.0.html)), dort allerdings (noch) nicht nach "deprecated", weil ich davon ausgegangen war, dass die dort befindlichen Module beim Releasewechsel ggf. komplett verschwinden, was für das noch "junge" Ausbauen keine gelungene Variante gewesen wäre.

Jetzt sind aber die "deprecated"-Module weiter im svn, von daher hätte ich das gleich dahin verschieben können...

Das ganze finde ich irgendwie irritierend, scheinbar gibt es keine allgemeine Vorgehensweise, wie "outdated" code auch wieder "ausgebaut" wird. Schon klar, dass ich das Modul in 12 Monaten selbst löschen kann, und bei HC ist es auch unproblematisch, weil er sowieso nur (noch) ein Klon von WDT war, betroffene User könnten also notfalls fast 1:1 ihre alten Definitionen anpassen. So wie ich diesen Thread hier verstanden hatte, war der Grund, warum es überhaupt dieses Verzeichnis gibt der, dass einzelne Maintainer veraltete Versionen und Vorgänger loswerden wollten (so wie ich jetzt mit HC). Ergänzend: Evtl. wäre es auch sinnvoll, Dinge da reinzupacken, um die sich keiner mehr kümmern will oder die bekanntermaßen nicht funktionieren? Vielleicht findet sich dann bei entsprechender Ankündigung jemand, der sich der Sache annehmen will, bevor es zu spät ist... (Notfalls kann man ja alte Pakete nach dem Code durchsuchen, falls man den doch noch benötigt...)

Meine eigentliche Frage:
Würde es sich nicht anbieten, die "deprecated"-Module nach irgendeiner noch zu definierenden Logik bei Releasewechseln komplett aus dem svn und/oder den Installationspaketen rauszunehmen, also z.B. nach zwei Jahren oder Veränderung von >=0.2 Releases? (Neben dem svn war es jedenfalls auch noch im zip).