contrib/deprecated angelegt

Begonnen von rudolfkoenig, 09 März 2018, 08:52:09

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Ich habe contrib/deprecated angelegt, und das seit etwa 4 Jahre in deprecated Zustand befindlichen 98_JsonList.pm dahin verschoben.

betateilchen

Zitat von: rudolfkoenig am 09 März 2018, 08:52:09
und das seit etwa 4 Jahre in deprecated Zustand befindlichen 98_JsonList.pm dahin verschoben.

Bist Du sicher, dass Du das getan hast?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Danke fuer den Hinweis, jetzt sollte die Datei tatsaechlich verschoben sein.

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Die naechsten Opfer: 82_LGTV.pm und 80_xxLG7000.pm auf Wunsch von Markus.

krikan

Markus und Rudi könntet ihr bitte MAINTAINER.txt entsprechend nachziehen. Danke.

rudolfkoenig

Habe JsonList beim LGTV Verschieben entfernt, sollte also im SVN sein, und morgen verteilt werden.

krikan

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...

Beta-User

Eine Verständnisfrage noch:

Ich hatte das Modul "Heating_Control" "nur" nach contrib verschoben (Diskussion hier), 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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files