Ankündigung

Einklappen
Keine Ankündigung bisher.

Versionsproblematik Plugins und Core

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    Versionsproblematik Plugins und Core

    Hi zusammen!

    Ich wollte hier kurz Probleme bezüglich der Versionsbezeichnungen von shngund Plugins festhalten und die Handhabung davon zur Diskussion stellen:
    • Unterversion von shng: Soweit ich mich erinnere gab es mal die Entscheidung: Unterversion nur zum Fixen von Dingen, die in der vorigen Version noch funktioniert hatten. Neue Vollversion ca. im Jahreszyklus. Diese Kombination erachte ich aber als recht unpraktisch, gerade was einen breiteren Test von Plugins anlangt. Beispielsweise kamen kurz nach der Fertigstellung von 1.5.1 einige Bugs in Kombination mit Smartplugins zum Vorschein (scheduler_change, etc.). Was haltet ihr davon, eine Unterversion wie 1.5.2 raus zu bringen, sobald Funktionen nicht so nutzbar sind/waren wie sie in der Doku der Master-Version festgehalten sind? z.B. gesammelt alle 3 Monate o.ä.
    • min Version bei Plugins/Develop-Version: Würde die aktuelle develop 1.6alphaXYZ heißen, könnte man in die plugin.yaml von aktuellen Plugins die korrekte Minimalversion 1.6 angeben und das Plugin trotzdem mit der Developversion testen. Aktuell sehe ich folgendes großes Problem: ein Plugin behauptet mit 1.5 zu funktionieren, funzt aber nur mit 1.6. Würde man das aber im plugin.yaml richtig hinterlegen, müsste jeder Tester den Wert zuerst manuell anpassen.
    • Plugin Version: Mir ist die Regelung bezüglich Pluginversionen derzeit unklar. Es gab ja mal den Ansatz, dass die ersten zwei Ziffern der shng Version entsprechen sollen, die benötigt wird. Also z.B. Plugin v1.6.1 -> automatisch min_version=1.6. Sehe ich das richtig, dass nun die Versionsnummer des Plugins quasi beliebig gewählt werden kann? Oder hatte ich das eh falsch in Erinnerung?

    #2
    Zum 3. Punkt: Der Ansatz die Major und Minor Version von der shng Version abzuleiten stammt aus der Zeit, als Plugins noch keine Metadaten hatten nd ist eigentlich überholt. In den Metadaten kann die Kompatibilität ja inzwischen über die Parameter sh_minversion und sh_maxversion festgelegt werden. Ich würde dazu plädieren die Plugin Versionsnummer von der shng Versionsnummer zu entkoppeln (da diese Konvention soowieso sehr unterschiedlich ausgelegt und implementiert wird)

    Generell: Plugin Versionsnummern sollten der Übersichtlichkeit halber normal auch nur <Major>.<Minor>.<Revision> bestehen, evtl. (im develop Branch) ergänzt um eine Buildnummer (<Major>.<Minor>.<Revision>.<Build> ).
    Viele Grüße
    Martin

    There is no cloud. It's only someone else's computer.

    Kommentar

    Lädt...
    X