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?

If theres noone -> easy solution, we need no instability period ATM.
If theres someone, i would ask that someone how long it needs to be
and write that down in APIchanges. Maybe as in "API is unstable becuase
of X until 2033-11-11

a new #define LIBAVCODEC_UNSTABLE could be added but izt feels a bit
overengeneered. This whole thing is more a exception, isnt it?

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Reply via email to