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

[Andreas Cadhalpun]

On 25.08.2015 11:03, Vittorio Giovara wrote:
> On Mon, Aug 24, 2015 at 11:43 PM, Andreas Cadhalpun
> <andreas.cadhalpun at googlemail.com> wrote:
>> On 24.08.2015 13:44, Vittorio Giovara wrote:
>>> On Tue, Jul 28, 2015 at 6:54 PM, Luca Barbato <lu_zero at gentoo.org> wrote:
>>>> On 28/07/15 15:41, Vittorio Giovara wrote:
>>>>> On Tue, Jul 28, 2015 at 2:40 PM, Luca Barbato <lu_zero at gentoo.org> wrote:
>>>>>> On 28/07/15 15:30, Vittorio Giovara wrote:
>>> I believe to see general consensus towards applying the set as is.
>>
>> There is no consensus for that.
> 
> 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.
And there have been more on ffmpeg-devel.

>>> I've added a skeleton to the wiki
>>> (https://wiki.libav.org/Migration/12) so that we can properly document
>>> the necessary changes before we release. Any help with that is of
>>> course welcome.
>>
>> I have a work-in-progress API-porting-guide.
> 
> 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.

> it mostly duplicates APIChanges

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

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

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

>>> 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?
> 
> I was afraid someone would point out it's less than two years old.

Why that? You apparently don't care that avcodec_alloc_frame was
deprecated less than two years ago.
And anyway, doing these removals strictly according to the calendar
doesn't make sense.

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.

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

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

What's your argument for keeping the ones you suggested?
In particular I'm interested in explanations for the following, unused APIs:
  [lavc]
    - FF_API_AC_VLC
    - FF_API_OLD_MSMPEG4
    - FF_API_ASPECT_EXTENDED
    - FF_API_ARCH_ALPHA
    - FF_API_QSCALE_TYPE
    - FF_API_MB_TYPE
    - FF_API_FAST_MALLOC
    - FF_API_NEG_LINESIZES
    - FF_API_IDCT_XVIDMMX
    - FF_API_INPUT_PRESERVED
    - FF_API_AFD
  [lavfi]
    - FF_API_AVFILTER_OPEN
    - FF_API_AVFILTER_INIT_FILTER
  [lavu]
    - FF_API_OPT_TYPE_METADATA
    - FF_API_DLOG

> I believe we went over and over explaining why it's a
> good a idea to remove those, not sure how beneficial it is to iterate
> once again.

Let me try to phrase it differently:
If it's a good idea to remove those, it's an even better idea to remove
all those, which you suggested to delay, because they are much less used.
But you didn't propose that. Why?

Best regards,
Andreas