On Wed, Jan 9, 2013 at 5:32 PM, Thomas Goyne <[email protected]> wrote:
> On Wed, 09 Jan 2013 01:48:15 -0800, Reinhard Tartler <[email protected]>
> wrote:
>
>> Btw, this is because of the ffmpegsource drama, right? Does this patch
>> actually help the ffmpegsource developers? I would be happy to include
>> additional #defines if, and only if, that would help them.
>
>
> Not particularly. In general we try to support every reasonably recent
> released version, so it's too late to fix it now.
>
> Having 53.21.1 and 53.21.0 be significantly different versions is an
> improvement over having two 51.21.0s, but it's still pretty terrible
> since it ignores even the most basic parts of semantic versioning like
> "bigger numbers come after smaller numbers".
>
> API version numbers are inherently not very compatible with making API
> changes on multiple branches. One possible solution would be to have
> separate non-sequential defines for each API change, so that they can be
> reordered or cherry-picked willy-nilly. A simpler solution would be to
> just not change the API in minor releases of stable versions, since
> that's generally one of the main points of stable branches.
What has been done in this case is that ffmpegsource needed this
specific API and decided to backport it themselves in a way that
clashed the backport in the stable release branch (i.e., by using
function names in the ff_*/ av_* namespace). Other options would have
also been available, but that's not the point here.
>From this story, I do think that in some cases, API backports are
called for, the challenge is that we need to provide a way to reliably
check for their presence. And above all, to communicate/announce these
changes more aggressively to avoid such an embarrassing drama.
We use FF_API functions to schedule deprecations/removals. Maybe we
can also use them for backported APIs? If done properly, this would
allow to significantly simplify the #ifdefery in ffmpegsource.
--
regards,
Reinhard
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
