On date Tuesday 2024-07-02 10:08:37 +0100, Andrew Sayers wrote: > Some notes about this version: > > As previously mentioned, I think this is better with all three patches, > but can live without #2. > > I think I've followed the deprecation instructions, but editing APIchanges > seems to imply needing a minor version bump? This patch includes said bump. >
> Zhao Zhili argued this bothers users for too little benefit - > I'd argue it's beneficial to confirm they haven't misused this feature > in a way that causes bugs in their code, but the old deprecation message > didn't make that clear enough. This version rephrases the @deprecated message > to speak directly to the maintainer. I agree the rename is a net improvement in the long term, giving that this will remove the developer cognitive load and possibly mistakes due to the misleading name, while the effort required to make the mechanical rename should be rather small - also there is no evidence that users are really using this API in their application code so probably the overall effort is close to zero in this case and it is only benefits the developers. While I agree with Anton that we should avoid duplication, for the usual arguments that a reference should avoid duplication of content as much as possible, which inevitably leads to inconsistent content when it is updated partially, leading to inconsistent information. _______________________________________________ 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".
