[vlc-devel] [RFC] Slimming LibVLC down

[Rémi Denis-Courmont]

On Mon, 1 Feb 2010 14:34:37 +0100, "Pierre d'Herbemont"
<pdherbemont at free.fr> wrote:
>> If we marked them as obsolete, we'd still have to carry them until
>> the next binary break. We can add a new function and preserve
>> compatibility. But we cannot remove or modify the prototype of an
>> old function.

> Well, depending how you link, if you don't use deprecated function
> you are safe.

That's simply not true.

In theory, this is just totally wrong. Backward compatibility is black or
white. If you removed a function, then you broke compatibility. It does not
matter how long the function has been deprecated.

In practice, this does not work. You will silently break applications that
do use the deprecated symbols. You will also not fool state-of-the-art
packaging systems who do track exported symbols.

In other words, backward compatibility is a property of a whole shared
object.
You can't split it to exported symbols, LIKE IT OR NOT. If we wanted
mediacontrol to be stable independent of LibVLC, the only way would have
been to ship it as a separate shared object. Now, it's too late. So
mediacontrol will go through its second breakage, just like LibVLC. And
mediacontrol shall become a separate library so as not to break again next
time LibVLC breaks.

>>> Remi, you forgot to mark API as deprecated before removing them.
>>
>> No. That's done on purpose.
> 
> I think it's bad practice when maintain an API.

I would like to remind you that LibVLC 1.1 does not maintain the API from
earlier version, so this is moot.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis