[FFmpeg-devel] [PATCH 00/26] Major library version bump
Marton Balint
cus at passwd.hu
Tue Jan 24 00:41:11 EET 2023
On Mon, 23 Jan 2023, Anton Khirnov wrote:
> Quoting Marton Balint (2023-01-21 23:00:52)
>>
>>
>> On Sat, 21 Jan 2023, Michael Niedermayer wrote:
>>
>>> On Sat, Jan 21, 2023 at 05:51:34PM +0100, Anton Khirnov wrote:
>>>> Quoting Michael Niedermayer (2023-01-20 03:05:09)
>>>>> PS: iam not sure i fully understood the reason behind why versions should be
>>>>> set to "wrong" values during some period, so as always i might be missing
>>>>> something
>>>>
>>>> The reason is that after the major bump, the API and ABI are declared to
>>>> be unstable for some period, so people can freely
>>>> - break ABI, e.g. by reordering struct members
>>>> - modify API added during the instability period in an arbitrary way
>>>> without a new major bump for every such change, that would be normally
>>>> required.
>>>>
>>>> My concern is that the instability period is quite long and there is
>>>> very little indication for our users that they cannot depend on the
>>>> ABI/API being stable. So I'm proposing to introduce some mechanism to
>>>> make this more visible for our callers.
>>>>
>>>> Alternatively, we could just not have an instability period at all.
>>>
>>> Does anyone plan to use the next bumps instability period for anything ?
>>> If so, i assume theres a good reason why it cannot be done without such
>>> period easily?
>>
>> AVCodecContext->frame_number should be changed to int64_t. I guess you
>> could do something similar which was done for buffer_size_t, but that
>> seems like a lot of extra work and ifdefry for questionable benefit.
>
> Not breaking callers seems like a very solid benefit to me.
I am not sure if I see your point, during unstable, you can break callers,
and I planned to do the change during unstable.
Regards,
Marton
More information about the ffmpeg-devel
mailing list