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

[James Almer]

On 9/8/2021 10:49 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:34
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] Why does this break FATE?
>>
>> On 9/8/2021 10:29 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:18
>>>> To: ffmpeg-devel at ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [PATCH] Why does this break FATE?
>>>>
>>>> On 9/8/2021 10:14 PM, Soft Works wrote:
>>>>> Test seek-lavf-asf failed. Look at tests/data/fate/seek-lavf-
>>>> asf.err for details.
>>>>> make: *** [/build/ffmpeg-git/tests/Makefile:256: fate-seek-lavf-
>>>> asf] Error 139
>>>>>
>>>>> $ cat tests/data/fate/seek-lavf-asf.err
>>>>> /build/ffmpeg-git/tests/fate-run.sh: line 78: 21786 Segmentation
>>>> fault      $target_exec $target_path/"$@"
>>>>>
>>>>>
>>>>> It's the same on both Windows/MSYS2 and Linux. Let's see how
>>>> patchwork results will be...
>>>>
>>>> Please, don't send patches just to have patchwork run FATE for
>> you.
>>>> It
>>>> litters the mailing list. Do it locally.
>>>
>>> As written above I _did_ run it locally on both Linux and
>> Windows/MSYS.
>>
>> That was more than enough to know that the failure you saw was not a
>> fluke.
> 
> Might be true, but it doesn't seem right to me that this is happening
> and submitting a patch for demonstration seemed to be an adequate
> measure to present the issue.
> 
>> Since we haven't had a release since the last major bump, we can
>> still
>> apply ABI (not API) breaking changes, if needed.
> 
> 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. In contrast, every new API addition requires 
its own minor or micro bump.

> 
> Anyway - will use minor bumps, then.
> 
> Thanks,
> 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".
>