[vlc-devel] [RFC] Slimming LibVLC down

[Pierre d'Herbemont]

2010/2/1 Rémi Denis-Courmont <remi at remlab.net>:
>
> 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.

No. "if deprecated function and how you link" is the important part.
Below you just agree with this.

> 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.

Remi, I stated, that *if* you don't use deprecated stuff you are
fine... Don't you think we should look forward having a stable API?
Ie, deprecate stuff and let user move gently to the new API? I don't
mean for 1.1 as we have already gone too far.

I think we should balance. And we need to be a bit pragmatic with
this, and leave the religion aside.

Pierre.