[FFmpeg-devel] FFmpeg 7.0 blocking issues

[Andrew Sayers]

On Mon, Jun 03, 2024 at 11:32:37PM +0200, Michael Niedermayer wrote:
> On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
[...]
> > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> > Debian. The list is available at [1]. So if you want ffmpeg X to be in
> > Debian Y or Ubuntu Z, X needs to be released at least half a year before
> > Y or Z freeze.
> 
> Is there something that ffmpeg can do to reduce this breakage ?
> (i know its a bit of a lame question as its API brekages but i mean
> can the policy we have about deprecating API/ABI be amended in some way
> to make this easier ?

A quick look through Sebastian's list suggests two main groups of issues:

* channel layout migration
* things that didn't have attribute_deprecated before being removed

There are probably ways to reduce migration issues (e.g. Anton's point about
frequent small changes), but the quick win is to use attribute_deprecated more.

To be clear - attribute_deprecated is already used a lot.  If those messages
were being ignored, we would expect to see more bugs reported for those things.
The fact that channel layout is the only deprecated functionality to get this
far suggests that attribute_deprecated is a good way to notify people about
all but the largest changes.

> Also am i correct that it should be easier if a X.1 with same API/ABI that is
> released 6 month after X.0 is targetet for the release ? Thats in fact kind
> of what i would have preferred anyway as the .1 likely has also fewer bugs
> 
> And last but not least, someone needs to write down when .0 and .1 releases should
> be made so I dont forget it :)

Whatever decision is made about this, it would be good to update the
attribute_deprecated macro to point to a URL that lays out the policy.
Something like:

#define attribute_deprecated __attribute__((deprecated("see <url> for details")))