Jedes Mal, wenn es eine neue VDR-Version gibt, bei der die APIVERSION nicht hochgezählt wird (weil sich das API nicht geändert hat), kommt wieder das Argument, dass es "irritierend" sein, wenn VDRVERSION und APIVERSION sehr ähnlich, aber doch nicht gleich sind. Und es sollte doch APIVERSION eine ganz andere Zahl sein, damit das vermieden wird. Setze ich APIVERSION immer gleich VDRVERSION, sind diese Nutzer dann zwar still, aber dann jammern (zurecht) jene, die viele Plugins verwalten und diese dann jedes Mal neu übersetzen müssen. Ich bin da dann auch jedes Mal hin- und hergerissen (wie man vielleicht an meinen Reaktionen sehen kann ;) ). Um vielleicht endlich mal Frieden in diese Angelegenheit zu bringen, greife ich mal den Vorschlag auf, einfach eine laufende Nummer für APIVERSION zu verwenden. Dazu folgende Gedanken: APIVERSION soll sich auch in APIVERSNUM widerspiegeln. APIVERSNUM muss auch in der neuen Variante gößer als 20609 sein. APIVERSION wird an allen Stellen als einfacher String behandelt, kann also beliebigen Inhalt haben. Wenn man mal in /usr/lib reinschaut sieht man, dass *.so-Dateien üblicherweise Versionsnummern haben, die aus drei durch Punkte getrennte Zahlen bestehen (daher auch das bisherige Format bei APIVERSION). Es gibt aber auch welche mit zwei Zahlen oder nur einer (letzteres meist Symlinks). APIVERSION könnte also eine einfache Zahl sein, ohne den Ablauf zu stören (habe ich getestet). Bisher gab es für die Plugins Dateien mit Namen libvdr-*.so.1.?.? und libvdr-*.so.2.?.?. Das neue Format sollte meiner Meinung nach mit libvdr-*.so.3 beginnen, um zumindest hier eine gewisse Kontinuität einzuhalten. Diese Aktion darf keine Änderungen in Plugin-Code (weder Source noch Makefile) verursachen. Unter Berücksichtigung all dieser Punkte wäre folgende Lösung möglich: (Code, 2 lines) Damit ergäben sich Dateinamen wie etwa libvdr-osddemo.so.3. APIVERSNUM braucht die 3 am Anfang, um Punkt 2 von oben zu erfüllen. Die nächste API-Version sähe dann so aus: (Code, 2 lines) Alle bisherigen #if APIVERSNUM < NNNNN Abfragen im Code bleiben davon unberührt. Die bisherige Möglichkeit, an einer solchen Stelle sofort sehen zu können, bei welcher VDR-Version sich das geändert hat, geht allerdings für künftige Werte von APIVERSNUM verloren. Irgendwann wird VDRVERSNUM (momentan 20701) in den Bereich von APIVERSNUM kommen, aber das spielt sich nur Code-Intern ab und schlägt nicht auf die Dateinamen durch. Und bis dahin sind es noch mindestens 29 Versionen (wenn ich mich nicht verrechnet habe) ;) . Ich bitte um Meinungen hierzu, vor allem, ob ich etwas Wichtiges übersehen habe.