Numerically-comparable equivalent of 'mpv-version' property

[fbriere]

There is (AFAIK) currently no "proper" way for a script to check which version of mpv is running, as the mpv-version property seems mostly intended for display purposes. It would be nice to have another property providing the mpv version in a numerically-comparable format, similar to MPV_CLIENT_API_VERSION.

(An alternative would be to parse mpv-version myself, but I doubt its format is ever guaranteed to be parsable.)

Motivation: I'm the author of a plugin where I try to maintain compatibility with older mpv releases (back to 0.21.0 so far). While the presence/absence of new properties/commands is obviously easy to determine (although command-list itself is a recent feature), other changes may be more difficult to detect. For example, change-list didn't work with the file-local-options/ prefix until the introduction of shared-script-properties, so I check for that instead; this is not only hackish but also fragile, as it will break if that property is ever removed/renamed.

[ghost]

Yeah, it's possible that the mpv-version string changes format (maybe when we drop the 0. or so?). But having a separate number that bumps on every interface change is also not nice for development.

[fbriere]

But having a separate number that bumps on every interface change is also not nice for development.

My phrasing may have been ambiguous; when I said "similar to MPV_CLIENT_API_VERSION", I only meant the format. The value itself would simply be a sortable representation of the actual mpv version, nothing more.

[Dudemanguy]

@fbriere: did you still want this by the way? I forgot I made a PR for this a long time ago (and I should change the name since mpv doesn't use semantic versioning technically). Adding this is trivial, but I'm not really certain what the numbering should be for an arbitrary git hash. Any preferences?

[na-na-hi]

IMO versioning implementation is a terrible way to handle compatibility since the number is meaningless by itself. It's better to version interface instead: each entry in property-list and command-list can also contain a version number which is increased every time the interface is changed. This is easier to handle on mpv side (no build-time generation) and the exact breaking changes can be programmatically detected by the user without needing to hardcode which commit hash broke them.

@Dudemanguy What do you think? I think this feature request isn't the correct approach to take in terms of compatibility handling.

[kasper93]

each entry in property-list and command-list can also contain a version number

I think it is too much trouble for little gain. Each each entry in property-list and command-list can be deprecated or removed. If a significant behavior change is applied, old property should be deprecated and new one created with distinct name. After deprecation period old property should be removed. I don't think everything has to be versioned.

I know we had breaking changes recently and we should be careful about it, by ensuring backward compatibility, not by requiring users to check version of each property they use.

[Dudemanguy]

Seems pretty overkill to me as well tbh.

[na-na-hi]

If a significant behavior change is applied, old property should be deprecated and new one created with distinct name. After deprecation period old property should be removed.

This would mean a constant name change (like loadfile2, loadfile3 like how Linux does). But after the old property is removed, the new property is stuck with the new name which seems unnatural.

Seems pretty overkill to me as well tbh.

That's how Wayland does it, and it even keeps implementations of old interface versions.

[Dudemanguy]

I don't think the time investment into this is worth it. Yeah libmpv technically exists (which just follows the usual C library practices), but mpv is primarily just an application. We don't even officially support anything older than the latest release. Why put all this effort into backwards compatibility for user scripts?