[FFmpeg-devel] [PATCH] Why does this break FATE?

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> James Almer
> Sent: Thursday, 9 September 2021 04:31
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Why does this break FATE?
> 
> On 9/8/2021 11:24 PM, Soft Works wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >> James Almer
> >> Sent: Thursday, 9 September 2021 03:57
> >> To: ffmpeg-devel at ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH] Why does this break FATE?
> >>
> >
> > [..]
> >
> >>>
> >>> Based on the fact that requirements are strict about MINOR bumps
> >> and
> >>> mandating them to be included in the very commit that is
> requiring
> >>> the bump, I didn't expect that there's a different strategy for
> >>> MAJOR bumps.
> >>
> >> A major bump is done once every few years to remove deprecated
> APIs
> >> and
> >> open the ABI for changes. After a major bump takes place, there's
> an
> >> "Unstable ABI" period where one can make such breaking changes
> >> (Altering
> >> field offsets in public structs, adding new fields or changing
> their
> >> types on structs that have their size tied to the ABI, changing
> >> public
> >> enum and #define values, etc).
> >>
> >> A single major bump should encompass every breaking change during
> >> this
> >> short "unstable" period.
> >
> > Why does there have to be an "unstable" period instead of making
> the
> > MAJOR bumps directly in those commits that are breaking ABI
> compatibility,
> > Is it about "saving" numbers?
> 
> To keep the bumping of major revision to a single number every few
> years, yes. We decided to go the opposite way of x264.
> Also, the FF_API defines would need to be updated way too often
> otherwise.

OK understood. Thanks a lot for explaining!

sw