[FFmpeg-devel] Major bump

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting James Almer (2021-04-05 13:57:12)
>> On 4/5/2021 8:09 AM, Anton Khirnov wrote:
>>> Hi,
>>> this patchset bumps major version of all the libraries and removes many
>>> deprecated APIs, as discussed at length during past months. Patches
>>> 11-16 will be squashed together on push, but are sent separately for
>>> ease of review. FATE passes (here at least).
>>>
>>> As agreed during the last developer call, I am disabling the
>>> uspp/mcdeint filters that depend on removed libavcodec APIs. They should
>>> be easy to re-enable if anyone finds the motivation to update them.
>>>
>>> I am postponing the removal of compute_muxer_pkt_fields() in lavf, along
>>> with usage of AVCodecContext.time_base for decoding, since removing them
>>> without breakage requires a fair bit of additional infrastructure that
>>> is not yet there. I have plans for all these and hopefully I'll get to
>>> it before the next bump.
>>>
>>> Carl asked during the last meeting for some reasoning for the bump. The
>>> general reasons are that
>>> - old APIs are unable to provide all the features of the new ones
>>>    (that's usually why new APIs are added)
>>> - old APIs tend to be harder to use correctly, they often have obscure
>>>    quirks or corner cases
>>> - maintaining compatibility wrappers for them is a major obstacle to
>>>    further development
>>> I'm appending some notes for the specific changes further down, they
>>> could be added to the wiki or the website news entry.
>>>
>>> Please comment,
>>
>> The deprecated APIs should be removed one by one before the commit that 
>> bumps the versions, so any potential issues or regressions can be 
>> bisected to the culprit instead of the "Bump and disable everything" 
>> commit. The latter was done last bump and it was a bit hectic.
> 
> I like that option less because it means there are commits in master
> that break ABI but don't change soname. And I never really saw
> bump-related bisecting problems, it's usually clear what the culprit is.
> But if others prefer to first remove and then bump then I won't fight
> for it very hard.
> I agree with James here. Bisectability is important and so are atomic
commits.

- Andreas