[libav-devel] [PATCH 20/20] Bump major versions of all libraries

Vittorio Giovara vittorio.giovara at gmail.com
Wed Aug 26 11:30:40 CEST 2015

On Wed, Aug 26, 2015 at 12:47 AM, Andreas Cadhalpun
<andreas.cadhalpun at googlemail.com> wrote:
> On 25.08.2015 11:03, Vittorio Giovara wrote:
>> There is, consensus does not need to be unanimous, and so far only you
>> have been expressing concerns (multiple times).
> That's not true.
> wm4, James and indirectly Ronald also had concerns.

Actually they were advocating to remove all the deprecated features,
and they mostly have been in favour of the proposed deprecations to my

> And there have been more on ffmpeg-devel.

And this is relevant how? ffmpeg is not bound to the deprecations or
removals libav does, and vice versa.

>> if you're talking about the patch set you sent it, I don't believe
>> it's a good idea adding yet-another-doc-file to the tree,
> Having this in the tree is important, because then one can make
> sure that whenever something gets deprecated the necessary
> documentation for API users gets added.

Not really, as humans are fallible, it is very easy to forget to
update a documentation file. Updating a checked-in is also much more
convoluted than a wiki page. See how many codecs are missing from
doc/general.texi as another example. A new file for this purpose is
just another maintenance burden which will not accomplish anything.

>> it mostly duplicates APIChanges
> No, APIchanges lacks code examples and it contains too much unrelated
> stuff to be useful as porting guide.

What unrelated stuff? Why are you complaining about this now?
APIChanges is a starting guide which contains the minimum changes one
should be aware of when updating the code, documentation can be found
elsewhere (on a wiki).

>> and its contents are much better off on a wiki,
> That has been tried and it didn't work that well. The current wiki pages
> don't even mention many API deprecations/removals.

Are you sure? https://wiki.libav.org/Migration/10 looks pretty
complete, feel free to amend it if you want to add more. Bonus, you
don't need git, mails or reviews for that since it's a just wiki page
everyone can edit.

>> where it can be quickly updated and edited. Your efforts are indeed
>> commendable and I look forward to seeing the wiki page I linked filled
>> with documentation.
> You can copy the API-porting-guide to the wiki, whenever a release is
> made.

Why? API-porting-guide as you envisioned should not exist in the first
place, and its contents should be written directly to the wiki. This
will encourage people to contribute rather than having a single guy do
all the work. Also, filling that wiki rather than repeating over and
over the same arguments here would be much more beneficial for

>>>> If no objections I'll push this set in the following days.
>>> Can you explain why you believe it makes any kind of sense to remove
>>> widely used APIs like FF_API_PIX_FMT/FF_API_AVCODEC_FRAME, while
>>> keeping completely useless ones like FF_API_MISSING_SAMPLE?
> And anyway, doing these removals strictly according to the calendar
> doesn't make sense.

Nor does "being widely used" or no deprecation would ever take place.
We've been over this multiple times and apparently you refuse to
acknowledge any arguments many developers made. I think we'll just
have to agree to disagree if you insist on this point.

> The reason for keeping deprecated APIs is, as you say, that
> "downstream users need time to update their applications".
> For widely used APIs this naturally takes longer than for rarely
> used ones.

No, the time needed to update an API depends on how convoluted the API
change is.
For example in porting get_buffer -> get_buffer2 you need to know what
you are doing whereas for avcodec_alloc_frame you need to change a
couple of functions calls. Once again "being widely used" is a moot
argument here.

>> Jokes aside, missing_sample can go as well if you insist,
> Yes, I do insist that the decision which APIs get removed now and which
> are kept makes some kind of sense.
> Apropos, delaying FF_API_NOCONST_GET_NAME also doesn't make any sense,
> because API users can't adapt to that before it happened.

I have no idea what you are talking about here. Feel free to send a
patch if you want additional removals to take place while this window
is open.

>> while for
>> the other two you mention do you have any other argument than being
>> "widely used"?
> That's a way better argument than your argument for FF_API_MISSING_SAMPLE.

You proposed to remove this, are you withdrawing your request? I am
not sure I follow you any more.

> What's your argument for keeping the ones you suggested?
> In particular I'm interested in explanations for the following, unused APIs:

Feel free to reread past discussions, search for "promise", I am sure
I mentioned this already.

Anyway, I think your position is clear to everyone now. I thank you
for your comments and effort you've been putting into this discussion,
however I don't believe there is any substantial claim justifying any
delay or adjustment to the proposed removals.


More information about the libav-devel mailing list