[vlc-devel] [PATCH] libvlc: add language and frame rate to libvlc_media_track_info_t

[Felix Paul Kühne]

Hello,

On Oct 9, 2012, at 5:45 PM, Rémi Denis-Courmont wrote:

> On Tue, 9 Oct 2012 17:17:22 +0200, Felix Paul Kühne
> <fkuehne.videolan at gmail.com> wrote:
>> On Oct 9, 2012, at 4:49 PM, Rémi Denis-Courmont wrote:
>> 
>>> On Tue,  9 Oct 2012 16:34:03 +0200, Rafaël Carré <funman at videolan.org>
>>> wrote:
>>>> From: Sébastien Toque <xilasz at gmail.com>
>>> 
>>> Changing the size of libvlc_media_track_info_t is not allowed, since it
>>> breaks binary compatibility.
>> 
>> Isn't this acceptable for major releases such as 2.1?
> 
> Sure. There are several conditions though:
> - You bring an important new feature or a major design fox. 
This is provided by this patch IMO. This is no major breakthrough, but it adds convenience information to be used by libvlc client applications.

> - You update the binary version numbers as appropriate (I do not even know
> how to do that except on Linux).
This is missing indeed. On OS X / BSD, it works the same way as on Linux btw. For Windows, you responded yourself.

> - You remove all the legacy LibVLC stuff that was only left for backward
> compatibility.
I don't think this is within the scope of this patch. This patch adds a feature. It's not a lets-remove-all-the-old-cruft-clean-up-patch. It might be a good idea to clean up the code when breaking it anyway, sure, valid point, but I don't see how this should be a requirement for adding a feature. it's not like that we removed VCD support to make room for BR to give a bad analogy.

> - You update the documentation.
Valid point. This should be done so libvlc user's can benefit from the new functionality.

> - You take adequate measures to avoid the same problem occurring again
> with the same family of functions (i.e. next time some bit of track info is
> added).
Do you really think this is needed? What is Sébastien provides more patches to add support for more track info until 2.1 is out? I mean, we are not in feature freeze yet.

>> I mean, x264's ABI breaks all the time, too…
> 
> On Linux, you can bump the SONAME version. On Windows, we avoid the
> problem by linking statically.
Same for iOS. On the Mac, well, we broke the API anyway within 2.1, so 3rd party applications will need to be updated anyway if they would like to use the new VLCKit. Additionally, VLCKit is provided on a per-app basis and not as a shared framework, so there no compatibility issues when using 2 separate client applications with different VLCKit versions. The binary version numbers are going to be different, too, btw.
So, this final point shouldn't be a blocker.

Cheers,

Felix