Manchmal ist es ja gut alte Zöpfe abzuschneiden und mit dem heutigen Wissen und Erfahrung ein Modul neu zu entwickeln oder an der ein oder anderen Stelle gravierende Änderungen vorzunehmen. Dabei muss ja auch immer die Hoheit des Benutzers und eine bereits bestehende Installation / Instanz berücksichtigt werden.
Ich überlege gerade, wie ich vorgehen kann, dass auch z.B. alte Variablen bestehen bleiben, zusätzlich werden neue angelegt, so dass der Nutzer Gelegenheit hat eventuelle Skripte umzubauen.
Meine Idee ist:
ein Konvertierungsattribute
ein Konvertierungsbutton in der Instanzkonfiguration
Führt der User die Konvertierung durch werden „alte“ Variablen gelöscht.
Wie kann ich denn jetzt unterscheiden, ob der User bereits eine bestehende Instanz hat und diese nur aktualisiert, dann benötige ich ja die Konvertierung durch den User.
Wird hingen eine Instanz neu erstellt, dann brauche ich ja die „alten“ Variablen nicht mehr erstellen, sondern kann direkt mit der neuen Version starten?
Nur so als Idee, könntest du dir nicht in einem Attribut merken, dass der User die Konvertierung schon ausgeführt, danach könntest du den Button doch auch wieder ausblenden.
Eine ganz andere Idee:
Warum machst du nicht ein ganz neues Modul ohne komplizierte Updateroutinen. Das alte Modul einfrieren und das neue Modul weiterpflegen. Somit könnten jene, die die Funktionien des neuen Moduls wollen/benötigen dieses installieren und die Überleitung relativ einfach selber machen. Alle anderen könnten am alten Modul bleiben, auch mit dem Wissen, dass dieses nicht mehr weiter gepflegt wird. Somit hat auch der Anwender die Möglichkeit, mal aufzuräumen und Dinge neu zu überdenken .
Damit kannst du alles neu machen und keiner hat Probleme mit bestehenden Variablen. Die Überleitung ist ja relativ einfach. Hab ich z.b. beim Wechsel des Viessmann Moduls auch machen müssen, da das Neue total anders war. Was aber nicht am Modulersteller lag (@paresy ), sondern an Viessmann.
Die Idee ist mir zwischenzeitlich auch gekommen und bei gravierenden Änderungen würde ich diese Variante vorziehen. Ich müsste nur überlegen, ob ich einen komplett neue Bibliothek erstelle oder nur ein neues Modul innerhalb der bestehenden Bibliothek. Das Modul befindet sich im Module Store… Mal sehen wie es sich entwickelt.
Ich habe das selbe Problem, wenn ich dass HUE Modul neu machen werde, dann wird auch genau sowas auf mich zukommen, die API hat sich so geändert, dass ich da ein komplett neues Modul bauen muss.
Ich erstelle ein neues Modul und benenne es etwas anders für den Module Store. Dann kann man das ursprüngliche Modul irgendwann mal still legen. Glaub das ist in unserem Fall die bessere Variante.
Aber an dem Punkt bin ich noch nicht.
2x das Selbe Modul im Store verwirrt aber nur die Benutzer, generell finde ich ein neu aufsetzten besser,. Es ist weniger zeitaufwendig, und sorgt für weniger Problemen. Auch solltest du dir überlegen ob du dir die Arbeit für die anderen machen willst (Umstellung auf das neue Modul).
Ich würde im Modulthread und im Store nur darauf verweisen das nach den update die Instanzen neu angelegt werden müssen, geben falls kannst du ja die neue Instanzen mit einer neuen ModulID belegen. so das die alten nicht mehr geändert werden. Dann würde ich noch im konfigurationsform auf die neuen Instanzen hinweisen.
Eine Möglichkeit wäre auch die Instanzen einfach umbenennen und die neuen wieder so zu nennen wie die alten Instanzen hießen.
Dann können die alten Instanzen noch eine gewisse Zeit im Modul bleiben, aber du musst nicht zwei Module im Store anbieten, dann gibst du den Hinweis wie @Acer90 es schon geschrieben hat.
.