[FFmpeg-devel] Major bump

[James Almer]

On 4/5/2021 4:20 PM, Anton Khirnov wrote:
> 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.

A couple dozen commits upstreamed simultaneously that remove the 
scheduled API one by one before the soname is bumped are not going to 
generate any inconvenience for anyone (It's not like we'll push them in 
batches during a extended period, which could result in people fetching 
a snapshot in the middle of it), and the benefits to bisection and 
history browsing are IMO worth it.