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. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
