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

[James Almer]

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.

> 
> softworkz
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>