Versionsnummer

    Nachdem die nächste Version von VDR 2.6.9 sein wird und ich zweistellige Nummern vermeiden möchte (also danach keine 2.6.10), überlege ich, folgende Änderungen zu machen:

    1. Keine Unterscheidung mehr zwischen "stable" und "developer" Version (gerade vs. ungerade mittlere Zahl). Die Versionsnummer wird einfach "hochgezählt" als wäre es eine normale Zahl (also 2.6.8, 2.6.9, 2.7.0, 2.7.1, ...) und hat ausser der Unterscheidung, welche Version "neuer" ist, keine Bedeutung mehr.
    2. VDRVERSION und APIVERSION immer gleich, da es in der Vergangenheit immer wieder zu Problemen/Missverständnissen gekommen ist, wenn sie unterschiedlich waren. Ausserdem sind die Rechner heutzutage deutlich schneller als vor zwanzig Jahren, da macht es nicht viel aus, bei einer neuen VDR-Version auch die Plugins neu zu übersetzen.

    Sollte eigentlich kein Problem sein und die meisten werden es vielleicht nicht mal bemerken, aber ich möchte doch vorher mal in die Runde fragen, ob es etwas gibt, das dagegen spricht.

    Gegen zweistellige Nummern spricht ebenso nichts, aber das ganze klingt problemlos.


    @2: dann evtl eines von beiden als deprecated #define des anderen.

    Ich hätte da gar nichts einzuwenden sondern würde eher noch die Frage in den Raum stellen, ob es schaden würde, einfach auch fertige Features als commit zwischen den Versionsnummern ins git zu pushen. Evtl. auch in einem develop branch, denn jeder testen kann.

    Ich glaube aber, die Diskussion gab es schon mal in dem git-Thread...

    Quote from wirbel

    Gegen zweistellige Nummern spricht ebenso nichts

    Ich möchte es halt so kompatibel wie möglich halten.

    <edit>

    Das hatte ich wohl falsch verstanden. Ich dachte, du meintest sowas wie 2.7, 2.8 etc. Aber du meintest wohl die "10" in 2.6.10. Nein, Problem wäre das sicher nicht, und es war ja auch nie definiert, dass die Zahlen einstellig sind - und wird es auch nicht werden, ich möchte lediglich per Konvention nur noch einstellige verwenden.

    </edit>

    Quote from wirbel

    @2: dann evtl eines von beiden als deprecated #define des anderen.

    Das sowieso.

    Quote from wirbel

    Gegen zweistellige Nummern spricht ebenso nichts, aber das ganze klingt problemlos.

    Das würde bei markad Anpassungen zur Folge haben, der aktuelle Stand erwartet zumindest an der letzten Stelle eine einstellige Number.

    Code
    APINUM = $(shell echo $(APIVERSION) | awk -F . '{print $$1 * 1000 + $$2 * 10 $$3}')

    Wäre aber auch kein Problem das anzupassen.

    Mir fällt aber gerade auf, da ist kein "+" drin. Also wird die 2-stellige Zahl dem String angehängt, kein Problem mit Minor Version >= 10.

    Aktuell kommt da "20608" raus, somit alles OK.

    Edited once, last by kfb77 ().

    Also, bei "wünsch Dir was" würde ich mir 2.6.10 / 20610 wünschen. Ich kann da keine Kompatibilitätsprobleme finden, und es gab ja auch schon 2.1.10.


    Vorteil: Es ist am transparentesten/klarsten, was gemeint ist. 2.7.1 müsstest Du erst erklären. Dann lieber 2.8.1 . Aber auch das müsste man erklären.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    Quote from kls

    Keine Unterscheidung mehr zwischen "stable" und "developer" Version

    Finde ich gut, ist ja schon lange so weit ausgereift und wird ja auch getestet.

    Quote from kls

    VDRVERSION und APIVERSION immer gleich, da es in der Vergangenheit immer wieder zu Problemen/Missverständnissen gekommen ist, wenn sie unterschiedlich waren. Ausserdem sind die Rechner heutzutage deutlich schneller als vor zwanzig Jahren, da macht es nicht viel aus, bei einer neuen VDR-Version auch die Plugins neu zu übersetzen.

    Fände ich schade. Für den Nutzer der nur ein paar Plugins hat sicher kein Thema aber vdr4arch komplett dauert bei mir Stunden.

    M-Reimer VDRVERSION und APIVERSION waren seit Version 2.1.1 (also seit über 10 Jahren) die meiste Zeit immer gleich. In dieser Zeit gab es 51 VDR-Versionen, davon waren nur bei 5 VDRVERSION und APIVERSION unterschiedlich. Zugegeben, in letzter Zeit habe ich sie immer gleich gesetzt, einfach um Diskussionen wie hier zu vermeiden (was aber anscheinend nicht gelingt). Es birgt aber auch eine gewisse Gefahr, sollte ich mal vergessen, APIVERSION hochzusetzen, wenn sich tatsächlich eine Schnittstelle ändert. Sowas bleibt u.U. lange unentdeckt, bevor es irgendwann zum Crash kommt.


    Also gut, dann lasse ich halt APIVERSION wie gehabt und bemühe mich, es nur hochzusetzen, wenn es wirklich nötig ist.

    Mein Script zum Erzeugen der Freigabenotiz werde ich so erweitern, dass es eine entsprechende Zeile erzeugt, je nachdem, ob VDRVERSION und APIVERSION gleich oder verschieden sind.

    Hier der aktuelle Stand meiner Überlegungen:

    1. VDRVERSION und APIVERSION bleiben wie gehabt.
    2. In der Freigabenotiz wird angegeben, ob Plugins neu übersetzt werden müssen (ist der Fall, wenn VDRVERSION und APIVERSION gleich sind).
    3. Keine Unterscheidung mehr zwischen "stable" und "developer" Version (gerade vs. ungerade mittlere Zahl).
    4. Die Versionsnummer wird einfach "hochgezählt" als wäre es eine normale Zahl (also 2.6.8, 2.6.9, 2.7.1, ...) und hat ausser der Unterscheidung, welche Version "neuer" ist, keine Bedeutung mehr.
    5. Alle Bestandteile der Versionsnummern sind einstellig.
    6. Bei Major und Minor wird die '0' nicht vergeben.
    7. Im GIT können Zwischenstände eingespielt werden, die noch keine neue Versionsnummer haben. Der jeweils neueste davon hat das Label "master". Diese Stände sind "work in progress" und wer sie verwendet sollte immer auch alle Plugins neu übersetzen.
    8. Sobald ein Stand als stabil angesehen wird erhält er eine neue VDRVERSION und ggf. APIVERSION, und wird im GIT mit "stable/latest" markiert. Für diesen Stand erfolgt dann eine Freigabemeldung.

    Ich hoffe, damit allen gerecht zu werden ;-).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login