Reform der APIVERSION?

Bei RE: [ANNOUNCE] VDR version 2.6.4 freigegeben war das auch schon mal ein Thema

Quote from kls

#define APIVERSNUM 30003

Wenn wir die beiden Versionsnummern von VDR und API semantisch deutlich entkoppeln wollen, sollte die API-Version keinesfalls so aussehen, als könnte sie irgendwie mit VDR 30x0y in Beziehung stehen.

Damit es beim VDR v3 wegen der Ähnlichkeit also nicht wieder zu Diskussionen kommt, was ja deine Sorge war, bräuchte man einen deutlich abweichenden (größeren) Basiswert. Weil das aber von der Notation her unschön werden kann, habe ich meinen etwas weitergehenden Vorschlag zur Diskussion gestellt, der den Basiswert einfach ausblendet.

In Fortführung des alten Ansatzes: Was spricht dann zum Beispiel gegen 100003? VDR v10 werden wir vermutlich nicht mehr sehen. Und 5-stellig für den VDR, 6-stellig für die API ist doch auch eine Art von Klassifikation…

Ich habe das hier auch erwähnt, aber ich bestehe nicht darauf... 😎

Ich kann die Argumentation von shofmann aber schon nachvollziehen.

Irgendwann nach X weiteren Jahren will der eine oder andere Entwickler vielleicht Support für VDR Versionen vor dieser Änderung aufgeben. Diese führende "3" bleibt trotzdem auf ewig.

Quote from M-Reimer

Diese führende "3" bleibt trotzdem auf ewig.

Deshalb hatte ich ja versucht, die über die Makros die numerische Codierung bei der Darstellung und dem Vergleich der Versionsnummer zu auszublenden. Die numerische Codierung träte nur noch in config.h des VDR in Erscheinung – und sonst nirgends mehr.

Also gut: Ich habe meine Gedanken und Argumente vorgetragen und lasse es nun dabei bewenden.

Falls in Zukunft jemand einen einfachen Gesamtüberblick über die API-Version braucht:

Das wird im Rahmen der Erzeugung des Mirrors vollautomatisch erzeugt.

Ich frage mich, ob man im vdr Makefile eventuell einen 'Grobcheck' der API Version unterbringen könnte.

nm -D ./vdr | grep " B \| D \| T \| V \| W " | c++filt | cut -d' ' -f1,2 --complement | sort | uniq > symbols.txt

gibt schon mal eine Liste der exportierten Symbole aus. Fragt sich nur - wie weiter.

Und was wäre der Mehrwert davon?

Ein check, ob man die API Version erhöhen muss, um zu signalisieren, dass Plugins neu gebaut werden müssen.

Ich bezweifle, dass sich das halbwegs (halb-)automatisch lösen lässt. Der Lösungsraum scheint mir dafür viel zu groß zu sein, denn dazu müsste man in den Header-Files alle "public"- bzw. "protected"-Elemente von Klassen sowie alle Symbole außerhalb von Klassen (#define, Typdefinitionen, globale Variablen usw.) zweier Commits vergleichen. Damit Variationen wie geänderte Formatierungen, Verschiebungen von Elementen innerhalb von Header-Files oder Umbenennung von Parametern in den Funktionsdefinitionen das Ergebnis nicht verfälschen, müsste man diese extrahierten Daten normalisieren. Und dann aus den normalisierten Datenbeständen sinnvolle Aktionen ableiten.

Ein Riesenaufwand also. Bislang hat Klaus das doch auch so ganz gut hinbekommen…

Deswegen benutze ich ja keine header files, sondern das binary.

Hilft das denn, um bspw. Änderungen auf Ebene des Prä-Compilers erkennen zu können? Auch die wirken schließlich auf das API ein und tragen zu der Frage bei, ob man neu kompilieren muss.

Ja

Wenn das tatsächlich automatisiert funktioniert, finde ich persönlich die Idee super.
Weil dann kriegt der Entwickler quasi gratis eine zweite Meinung und kann ggf. noch genauer hinschauen, ob die API-Version angepasst werden muss oder nicht.

ich habe da mal eine Frage.

Meine ganzen VDR-Plugins sind gegen vdr-2.6.9 kompiliert, wenn ich nun den vdr auf 2.7.2 update, fkt. dann die
Plugin's noch (kann es jetzt nicht so einfach testen), oder muss ich die ganzen Plugins neu übersetzen ?